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

[Simon Josefsson <[e-mail]>]

Kurt Zeilenga <[e-mail]> 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
>>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3154nEt074247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Mar 2008 22:04:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3154n6e074245; Mon, 31 Mar 2008 22:04:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3154kcP074237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 31 Mar 2008 22:04:48 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JgYfp-0003Jw-6s for [e-mail]; Tue, 01 Apr 2008 05:04:41 +0000
Received: from hmbg-d9b88e27.pool.mediaways.net ([217.184.142.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 01 Apr 2008 05:04:41 +0000
Received: from nobody by hmbg-d9b88e27.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 01 Apr 2008 05:04:41 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Date:  Tue, 1 Apr 2008 07:06:55 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 69
Message-ID: <fssfp0$fap$[e-mail]>
References:  <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e27.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:
=20
> The group has determined that DIGEST-MD5 (RFC2831) is not suitable =20
> for progression on the Standards Track due to interoperability,=20
> internationalization, and security concerns.

Interperability and deployment might be a problem.  The intended
compatibility with RFC 2617 has a problem with an 2617 erratum.
Apparently nobody wants more than authentication, and then a
design offering confidentiality is overkill.

What I18N concerns ?  SASLPREP bound to Unicode 3.2 isn't very
attractive when IDNAbis wants to use whatever Unicode offers,
but that is a 2831bis concern.

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

> The replacement mechanism is expected to be "better than"
> DIGEST-MD5 from a number of perspectives including=20
> interoperability, internationalization, and security.

Better than DIGEST-MD5 wrt to interoperability is no challenge,
better than CRAM-MD5 while not being more complex could be more
interesting for deployment. =20

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

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

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

> Negotiated key hardening iteration count,

When H(x) is not "hard enough", then H(H(x)) shuffling the bits=20
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".

> 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=20
"not good enough" - especially if it knows that there used to
be a better D when not talking to an attacker.

> 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 ?
=20
> Additionally, the WG will deliver a document summarizing its=20
> DIGEST-MD5 concerns and requesting RFC 2831 be moved to =20
> Historic status.

What will the WG do with standards having a normative reference
to RFC 2831 ?  I've heard that the XMPP folks try to get rid of
DIGEST-MD5, so that's hopefully soon out of the way.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2VL7XXJ046430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Mar 2008 14:07:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2VL7XPi046429; Mon, 31 Mar 2008 14:07:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2VL7WCK046423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 31 Mar 2008 14:07:33 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.197] ([75.141.230.206]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m2VL7UNm018481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Mon, 31 Mar 2008 21:07:31 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Date: Mon, 31 Mar 2008 14:07:24 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.919.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2VF2TUE018441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Mar 2008 08:02:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2VF2TDJ018440; Mon, 31 Mar 2008 08:02:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m2VF2QjR018431 for <[e-mail]>; Mon, 31 Mar 2008 08:02:29 -0700 (MST) (envelope-from [e-mail])
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa05080; 31 Mar 2008 11:01 EDT
Date: Mon, 31 Mar 2008 11:01:19 -0400 (EDT)
From: Jeffrey Hutzelman <[e-mail]>
X-X-Sender:  <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
cc: Nicolas Williams <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, <[e-mail]>
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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.


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.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2VAbKqG095929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Mar 2008 03:37:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2VAbKpA095928; Mon, 31 Mar 2008 03:37:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2VAbGvx095918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 31 Mar 2008 03:37:18 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JgHO1-0004pE-Uq; Mon, 31 Mar 2008 12:37:09 +0200
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx8.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JgHO1-0006IP-In; Mon, 31 Mar 2008 12:37:09 +0200
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JgHO1-0007Zo-46; Mon, 31 Mar 2008 12:37:09 +0200
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 31 Mar 2008 12:37:09 +0200
To: Jeffrey Hutzelman <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: AAAA3C238F16067C838EC050802E713A270220B8
X-UiO-SR-test: 3B046BA44D6F37DA0C1E2DAF8CED200B65ED4EB7
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 578 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman writes:
><[e-mail]> wrote:
>>Nicolas Williams writes:
>>>On Tue, Mar 18, 2008 at 03:31:03PM +0100, Hallvard B Furuseth wrote:
>>>> 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.
>>>
>>> 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 :(
>>
>> 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.
> (...)
> Nico is right, and not.  A mechanism-negotiating mechanism is generally a
> bad idea, (...)
>
> 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.

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

> (...)
>>> 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.
>>
>> 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, of course, you do this:
>
>> 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.
>
> Which seems to me like an entirely reasonable approach for people who are
> concerned about that issue.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2U3tc5G083899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Mar 2008 20:55:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2U3tc4b083898; Sat, 29 Mar 2008 20:55:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2U3tbsp083892 for <[e-mail]>; Sat, 29 Mar 2008 20:55:38 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 29 Mar 2008 20:55:28 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sat, 29 Mar 2008 20:55:24 -0700 (PDT)
From: [e-mail]
Cc: [e-mail], Chris Newman <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Sat, 29 Mar 2008 20:54:50 -0700 (PDT)
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-reply-to: "Your message dated Thu, 27 Mar 2008 22:58:29 +0100" <[e-mail]>
References: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
To: Simon Josefsson <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206849330; h=From:	 Date:Subject:MIME-version:Content-type; b=DMd93RxITaLxD3ByuqAi7Pl9C Jo34STTL733FNLfgdhoPEIObknfPRTTqzCdyuf4nXSgXO7QKSbVFMUlhqWvNw==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Maybe we can short-circuit this discussion.  Given the trade-offs here,
> I propose to use HMAC-SHA-1.  Would you or anyone else object to that?

I think HMAC-SHA-1 makes all kinds of sense.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2S1cWHH000974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 18:38:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2S1cWIA000973; Thu, 27 Mar 2008 18:38:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2S1cOtp000949 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 27 Mar 2008 18:38:30 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jf3Xx-0006yJ-6s for [e-mail]; Fri, 28 Mar 2008 01:38:21 +0000
Received: from hmbg-d9b88e10.pool.mediaways.net ([217.184.142.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 28 Mar 2008 01:38:21 +0000
Received: from nobody by hmbg-d9b88e10.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 28 Mar 2008 01:38:21 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Date:  Fri, 28 Mar 2008 02:40:40 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 12
Message-ID: <fshi65$trg$[e-mail]>
References:  <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F><[e-mail]><[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e10.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

> I propose to use HMAC-SHA-1.  Would you or anyone else object
> to that?

Yes, for the known reasons, I don't trust that SHA-1/2 is okay.

Unrelated, the PBKDF2 RFC and RMX draft have no examples to
check that implementations actually does what the authors
think it should do. =20

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RMWhG4044626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 15:32:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2RMWhiM044625; Thu, 27 Mar 2008 15:32:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RMWdMr044615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 27 Mar 2008 15:32:42 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2RMWaw9019534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 23:32:36 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080327:[e-mail]::H64faJgjLh78bb2i:BOt
X-Hashcash: 1:22:080327:[e-mail]::g8vi51IXy7mftS4v:5Xw5
X-Hashcash: 1:22:080327:[e-mail]::NuyHQfOaBtakwRCj:7oDx
Date: Thu, 27 Mar 2008 23:32:36 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Thu, 27 Mar 2008 17:22:40 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Thu, Mar 27, 2008 at 10:58:29PM +0100, Simon Josefsson wrote:
>> Maybe we can short-circuit this discussion.  Given the trade-offs here,
>> I propose to use HMAC-SHA-1.
>
> +1
>
> Make that the required to implement algorithm.

Agreed.

> Also provide for HMAC-SHA-256.  Then we can later (years later) update
> the spec to require HMAC-SHA-256.

Provide for in what way?

Including negotiation of hash algorithm in the mechanism?

Have the hash algorithm be part of the SASL mechanism name and the
GSS-API OID?

Specify that when storing password-equivalents that servers should store
a HMAC-SHA-256 variant for future compatibility?

Thanks,
/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RMMpMB043976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 15:22:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2RMMpqF043975; Thu, 27 Mar 2008 15:22:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RMMjst043961 for <[e-mail]>; Thu, 27 Mar 2008 15:22:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2RMMjl1022197 for <[e-mail]>; Thu, 27 Mar 2008 22:22:45 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2RMMfDf062685 for <[e-mail]>; Thu, 27 Mar 2008 16:22:41 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2RMMfDn026557; Thu, 27 Mar 2008 17:22:41 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2RMMeRo026556; Thu, 27 Mar 2008 17:22:40 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 27 Mar 2008 17:22:40 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, [e-mail], Chris Newman <[e-mail]>, [e-mail]
References: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Mar 27, 2008 at 10:58:29PM +0100, Simon Josefsson wrote:
> Maybe we can short-circuit this discussion.  Given the trade-offs here,
> I propose to use HMAC-SHA-1.

+1

Make that the required to implement algorithm.  Also provide for
HMAC-SHA-256.  Then we can later (years later) update the spec to
require HMAC-SHA-256.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RLwbaJ041835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 14:58:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2RLwbh9041834; Thu, 27 Mar 2008 14:58:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RLwX4Z041825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 27 Mar 2008 14:58:36 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2RLwTEW014509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 22:58:30 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]> (ned's message of "Thu, 27 Mar 2008 12:03:48 -0700 (PDT)")
References: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080327:[e-mail]::667qi+sPAOGqfhN8:3ywo
X-Hashcash: 1:22:080327:[e-mail]::22s1BUpsYpEScdmi:82d7
X-Hashcash: 1:22:080327:[e-mail]::tM4lH5Gm8r6rM5ga:Fj9K
Date: Thu, 27 Mar 2008 22:58:29 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Maybe we can short-circuit this discussion.  Given the trade-offs here,
I propose to use HMAC-SHA-1.  Would you or anyone else object to that?

/Simon

[e-mail] writes:

>> Chris Newman <[e-mail]> writes:
>
>> > --On March 21, 2008 12:50:26 -0400 Sam Hartman <[e-mail]>
>> > wrote:
>> >> 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 a theoretical security viewpoint, I would go with SHA-256 as
>> >> it's best
>> > available algorithm choice today.
>> >
>> > But a security mechanism that doesn't deploy provides zero incremental
>> > security to the community regardless of how strong the theoretical
>> > security happens to be.
>> >
>> > So I consider the question "will this deploy?" significantly more
>> > important to the security of the mechanism than any particular choice
>> > of algorithm. On that basis, any security algorithm that is widely
>> > deployed and used in application-layer code (e.g. MD5, HMAC) has a big
>> > advantage over algorithms that have not deployed in application-layer
>> > code.
>> >
>> > I know MD5 won't be a deployment barrier.
>> > I think SHA-1 won't be a deployment barrier.
>> > I think SHA-256 will be a deployment barrier.
>> >
>> > So I presently lean towards SHA-1, but I'd like statements from likely
>> > or potential implementers about the algorithms we're discussing.
>
>> I would not implement a new protocol with MD5 in it at this point.
>
>> Using HMAC-SHA-1 would be ok with me, although I would prefer
>> HMAC-SHA-256.
>
>> > SHA-256 isn't in my code toolkit, is not something I can code from
>> > scratch and finding a cross-platform way to use it that's thread &
>> > library safe and has a company approved OSS is not something I have
>> > investigated.  I can't make a commitment until I investigate it.
>
>> I suggest you read RFC 4648, and look at the source code provided in it.
>> An implementation donated into the public domain is available from:
>> <http://people.redhat.com/drepper/SHA-crypt.txt>.
>
> You're missing the point. Of course Chris can read RFC 4648, or do a Google
> search, or whatever, and dredge up some code implementing SHA-256. Anyone can
> who isn't an idiot, and Chris is no idiot.
>
> The problem is that finding the necessary code, building it, testing it,
> integrating it into a complex product environment, is a nonnegligable amount of
> work. And that's just for a straightforward product integration exercise - it
> gets a lot more fun once you factor in support for crypto acceleration
> hardware, or support for special processor instructions for better performance.
>
> I get all this stuff for free, including hardware acceleration support, for MD5
> and SHA-1 from multiple existing toolkits. Support for SHA-256 is much more
> limited, and that, like it or not, is a barrier to deployment.
>
> 				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RJP9U6030583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 12:25:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2RJP9Sf030582; Thu, 27 Mar 2008 12:25:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RJP720030574 for <[e-mail]>; Thu, 27 Mar 2008 12:25:08 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 27 Mar 2008 12:25:06 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 27 Mar 2008 12:25:03 -0700 (PDT)
From: [e-mail]
Cc: Chris Newman <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Thu, 27 Mar 2008 12:03:48 -0700 (PDT)
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-reply-to: "Your message dated Thu, 27 Mar 2008 11:36:16 +0100" <[e-mail]>
References: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F> <[e-mail]>
To: Simon Josefsson <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206645906; h=From:	 Date:Subject:MIME-version:Content-type; b=ypCCh4OfSWXoYmvJrF0DM1C/e nAbJggABgOQBpnoiyiL80+QMryIHMf9m47NWrdwMirbS5zDQLWojgr8CnKZgg==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Chris Newman <[e-mail]> writes:

> > --On March 21, 2008 12:50:26 -0400 Sam Hartman <[e-mail]>
> > wrote:
> >> 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 a theoretical security viewpoint, I would go with SHA-256 as
> >> it's best
> > available algorithm choice today.
> >
> > But a security mechanism that doesn't deploy provides zero incremental
> > security to the community regardless of how strong the theoretical
> > security happens to be.
> >
> > So I consider the question "will this deploy?" significantly more
> > important to the security of the mechanism than any particular choice
> > of algorithm. On that basis, any security algorithm that is widely
> > deployed and used in application-layer code (e.g. MD5, HMAC) has a big
> > advantage over algorithms that have not deployed in application-layer
> > code.
> >
> > I know MD5 won't be a deployment barrier.
> > I think SHA-1 won't be a deployment barrier.
> > I think SHA-256 will be a deployment barrier.
> >
> > So I presently lean towards SHA-1, but I'd like statements from likely
> > or potential implementers about the algorithms we're discussing.

> I would not implement a new protocol with MD5 in it at this point.

> Using HMAC-SHA-1 would be ok with me, although I would prefer
> HMAC-SHA-256.

> > SHA-256 isn't in my code toolkit, is not something I can code from
> > scratch and finding a cross-platform way to use it that's thread &
> > library safe and has a company approved OSS is not something I have
> > investigated.  I can't make a commitment until I investigate it.

> I suggest you read RFC 4648, and look at the source code provided in it.
> An implementation donated into the public domain is available from:
> <http://people.redhat.com/drepper/SHA-crypt.txt>.

You're missing the point. Of course Chris can read RFC 4648, or do a Google
search, or whatever, and dredge up some code implementing SHA-256. Anyone can
who isn't an idiot, and Chris is no idiot.

The problem is that finding the necessary code, building it, testing it,
integrating it into a complex product environment, is a nonnegligable amount of
work. And that's just for a straightforward product integration exercise - it
gets a lot more fun once you factor in support for crypto acceleration
hardware, or support for special processor instructions for better performance.

I get all this stuff for free, including hardware acceleration support, for MD5
and SHA-1 from multiple existing toolkits. Support for SHA-256 is much more
limited, and that, like it or not, is a barrier to deployment.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RAaOg6078484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 03:36:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2RAaOBv078483; Thu, 27 Mar 2008 03:36:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RAaMFA078471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 27 Mar 2008 03:36:23 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2RAaGfZ012382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 11:36:17 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080327:[e-mail]::VkUTEC6JdPl8czzR:NGNx
X-Hashcash: 1:22:080327:[e-mail]::sDH8OfL8z22mRmJ4:Nq5c
Date: Thu, 27 Mar 2008 11:36:16 +0100
In-Reply-To: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 24 Mar 2008 18:16:18 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> --On March 21, 2008 12:50:26 -0400 Sam Hartman <[e-mail]>
> wrote:
>> 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 a theoretical security viewpoint, I would go with SHA-256 as
>> it's best 
> available algorithm choice today.
>
> But a security mechanism that doesn't deploy provides zero incremental
> security to the community regardless of how strong the theoretical
> security happens to be.
>
> So I consider the question "will this deploy?" significantly more
> important to the security of the mechanism than any particular choice
> of algorithm. On that basis, any security algorithm that is widely
> deployed and used in application-layer code (e.g. MD5, HMAC) has a big
> advantage over algorithms that have not deployed in application-layer
> code.
>
> I know MD5 won't be a deployment barrier.
> I think SHA-1 won't be a deployment barrier.
> I think SHA-256 will be a deployment barrier.
>
> So I presently lean towards SHA-1, but I'd like statements from likely
> or potential implementers about the algorithms we're discussing.

I would not implement a new protocol with MD5 in it at this point.

Using HMAC-SHA-1 would be ok with me, although I would prefer
HMAC-SHA-256.

> SHA-256 isn't in my code toolkit, is not something I can code from
> scratch and finding a cross-platform way to use it that's thread &
> library safe and has a company approved OSS is not something I have
> investigated.  I can't make a commitment until I investigate it.

I suggest you read RFC 4648, and look at the source code provided in it.
An implementation donated into the public domain is available from:
<http://people.redhat.com/drepper/SHA-crypt.txt>.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QLXqNe012530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 14:33:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QLXqdX012529; Wed, 26 Mar 2008 14:33:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QLXnRL012516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 26 Mar 2008 14:33:51 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2QLXmgd017114 for <[e-mail]>; Wed, 26 Mar 2008 14:33:48 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 26 Mar 2008 14:33:48 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 26 Mar 2008 14:33:32 -0700 (PDT)
Date: Mon, 24 Mar 2008 18:16:18 -0700
From: Chris Newman <[e-mail]>
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
To: [e-mail]
Message-id: <16FC19DDFCF4C82D027D8EBC@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On March 21, 2008 12:50:26 -0400 Sam Hartman <[e-mail]> 
wrote:
> 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 a theoretical security viewpoint, I would go with SHA-256 as it's best 
available algorithm choice today.

But a security mechanism that doesn't deploy provides zero incremental 
security to the community regardless of how strong the theoretical security 
happens to be.

So I consider the question "will this deploy?" significantly more important 
to the security of the mechanism than any particular choice of algorithm. 
On that basis, any security algorithm that is widely deployed and used in 
application-layer code (e.g. MD5, HMAC) has a big advantage over algorithms 
that have not deployed in application-layer code.

I know MD5 won't be a deployment barrier.
I think SHA-1 won't be a deployment barrier.
I think SHA-256 will be a deployment barrier.

So I presently lean towards SHA-1, but I'd like statements from likely or 
potential implementers about the algorithms we're discussing.  Here's my 
statement as an implementer:

I can commit to implementing this mechanism if it uses any combination of 
HMAC, MD5, SHA-1, iterated-hash, or PBKDF-2.  I can not commit to 
implementing this mechanism if it uses SHA-256.  SHA-256 isn't in my code 
toolkit, is not something I can code from scratch and finding a 
cross-platform way to use it that's thread & library safe and has a company 
approved OSS is not something I have investigated.  I can't make a 
commitment until I investigate it.

		- Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LIV1Nw038878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 11:31:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2LIV1j6038877; Fri, 21 Mar 2008 11:31:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LIV0h2038871 for <[e-mail]>; Fri, 21 Mar 2008 11:31:00 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 109294775; Fri, 21 Mar 2008 14:30:55 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Date: Fri, 21 Mar 2008 14:30:54 -0400
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Fri, 21 Mar 2008 12:29:24 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Nicolas" == Nicolas Williams <[e-mail]> writes:

    Nicolas> On Fri, Mar 21, 2008 at 12:47:05PM -0400, Sam Hartman
    Nicolas> wrote:
    >> Is it?  I'm not sure sub-negotiation would be valuable for this
    >> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LHTURJ034297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 10:29:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2LHTU80034296; Fri, 21 Mar 2008 10:29:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LHTTl9034289 for <[e-mail]>; Fri, 21 Mar 2008 10:29:30 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2LHTSxg013228 for <[e-mail]>; Fri, 21 Mar 2008 17:29:29 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2LHTSi0028081 for <[e-mail]>; Fri, 21 Mar 2008 11:29:28 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2LHTSrZ022212; Fri, 21 Mar 2008 12:29:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2LHTONk022211; Fri, 21 Mar 2008 12:29:24 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 21 Mar 2008 12:29:24 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Mar 21, 2008 at 12:47:05PM -0400, Sam Hartman wrote:
> Is it?  I'm not sure sub-negotiation would be valuable for this
> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LGoWgU030825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 09:50:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2LGoWad030824; Fri, 21 Mar 2008 09:50:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LGoVL1030818 for <[e-mail]>; Fri, 21 Mar 2008 09:50:31 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6F65D4775; Fri, 21 Mar 2008 12:50:26 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F>
Date: Fri, 21 Mar 2008 12:50:26 -0400
In-Reply-To: <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 17 Mar 2008 17:48:14 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

    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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LGlLUX030621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 09:47:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2LGlL9h030620; Fri, 21 Mar 2008 09:47:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LGlHaK030607 for <[e-mail]>; Fri, 21 Mar 2008 09:47:20 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 03CA44775; Fri, 21 Mar 2008 12:47:06 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F>
Date: Fri, 21 Mar 2008 12:47:05 -0400
In-Reply-To: <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 17 Mar 2008 17:48:14 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Chris" == Chris Newman <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2KCcn1b072780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2008 05:38:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2KCcn8i072779; Thu, 20 Mar 2008 05:38:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2KCcjZt072772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 20 Mar 2008 05:38:47 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JcK2X-0002oU-C1 for [e-mail]; Thu, 20 Mar 2008 12:38:37 +0000
Received: from hmbg-d9b88e36.pool.mediaways.net ([217.184.142.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 20 Mar 2008 12:38:37 +0000
Received: from nobody by hmbg-d9b88e36.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 20 Mar 2008 12:38:37 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Date:  Thu, 20 Mar 2008 13:41:02 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 54
Message-ID: <frtls2$muh$[e-mail]>
References:  <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <froqjb$3v2$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e36.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:
=20
>>> I think our choice should be between HMAC-SHA-1 and HMAC-SHA-256.
>> I'll ignore it then.
> 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.=20
<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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J1AccV025168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 18:10:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2J1Acxc025167; Tue, 18 Mar 2008 18:10:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J1AaeB025158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 18:10:37 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-162c.ietf71.ietf.org (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2J1AU7B022632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 21:10:30 -0400 (EDT)
Date: Tue, 18 Mar 2008 21:10:30 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, March 18, 2008 06:01:10 PM +0100 Hallvard B Furuseth 
<[e-mail]> wrote:

>
> Nicolas Williams writes:
>> On Tue, Mar 18, 2008 at 03:31:03PM +0100, Hallvard B Furuseth wrote:
>>> 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.
>>
>> 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.
>
> 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.

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

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.

>> 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.
>
> 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, of course, you do this:

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

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

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J0jnVq023234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 17:45:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2J0jn8v023233; Tue, 18 Mar 2008 17:45:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J0jlsK023227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 17:45:48 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-162c.ietf71.ietf.org (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2J0jjuJ022230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 20:45:46 -0400 (EDT)
Date: Tue, 18 Mar 2008 20:45:46 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: Chris Newman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>
> On Tue, Mar 18, 2008 at 06:21:44PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > 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).
>>
>> If I understand your scenario, it may be that it can be solved easily
>> with unmodified SCRAM, see my response to Jeff.
>
> If you mean this:
>
>> >> 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 '[e-mail]', '[e-mail]' for each of
>> >> the servers in that realm.  The enrollment process could push out the
>> >> password-equivalent hash to each server.
>> >
>> > Ick.
>>
>> 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.
>
> 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.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J0g7Zt022820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 17:42:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2J0g7Ek022819; Tue, 18 Mar 2008 17:42:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J0g3t3022809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 17:42:04 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-162c.ietf71.ietf.org (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2J0fppD022158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 20:41:51 -0400 (EDT)
Date: Tue, 18 Mar 2008 20:41:51 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: Chris Newman <[e-mail]>, Tom Yu <[e-mail]>, [e-mail], [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <44ADB860B3FF5E9FF13784B6@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, March 18, 2008 05:05:46 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

>
> On Tue, Mar 18, 2008 at 10:47:37PM +0100, Simon Josefsson wrote:
>> Jeffrey Hutzelman <[e-mail]> writes:
>> > I'm seeing an awful lot of "GS2 is going to make the wire encoding more
>> > complicated!  It's binary; binary is always complicated!" and similar
>> > FUD. I really wish people would stop spreading that, RIGHT NOW, and go
>> > actually read (or re-read) the documents in question.
>>
>> For GS2, I think binary isn't an unreasonable choice, and I agree with
>> you.  I also think that there is some merit to having textual protocols,
>> and I think making our DIGEST-MD5 successor textual would be nice.
>
> There's very little binary anything in GS2:
>
>  - two 32-bit unsigned network byte order lengths
>  - another 32-bit quantity: maxbuf for security layers
>  - a pair of one-byte flags for security layer and channel-binding
>    negotiation
>  - the actual GSS-API mechanism tokens in the authentication exchanges
>
> Base64-encoding the GSS tokens would allow us to get rid of those two
> lengths

It would, but it would be otherwise unnecessary and would lead to a 
double-base64 in many cases.  That's a lot of bloat, not to mention making 
it more difficult to debug things when the underlying mechanism is 
text-based like SCRAM.  It makes the pure-SASL implementation of SCRAM look 
like "construct this string of key=value,..., then base-64-encode it.  Then 
(usually) base-64 encode it again."  I see developers of 
non-framework-using applications getting confused, and only applying the 
encoding once, or to the wrong thing, or....

I agree the flags and maxbuf can be expressed textually.  I submit that the 
lengths also can be, such that one might send

ctxlen=NNN\n<context token><wrap token>

(note the length of the wrap token is implicit.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IMhOIq012042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 15:43:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IMhOsu012041; Tue, 18 Mar 2008 15:43:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IMhM0L012033 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 15:43:22 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2IMhLLc004403 for <[e-mail]>; Tue, 18 Mar 2008 22:43:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IMhLGc011905 for <[e-mail]>; Tue, 18 Mar 2008 16:43:21 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IMhL4x018613; Tue, 18 Mar 2008 17:43:21 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IMhLu3018612; Tue, 18 Mar 2008 17:43:21 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 17:43:21 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Chris Newman <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Chris Newman <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
References: <44ADB860B3FF5E9FF13784B6@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 11:23:37PM +0100, Simon Josefsson wrote:
> 
> Nicolas Williams <[e-mail]> writes:
> 
> > On Tue, Mar 18, 2008 at 10:47:37PM +0100, Simon Josefsson wrote:
> >> Jeffrey Hutzelman <[e-mail]> writes:
> >> > I'm seeing an awful lot of "GS2 is going to make the wire encoding more
> >> > complicated!  It's binary; binary is always complicated!" and similar FUD.
> >> > I really wish people would stop spreading that, RIGHT NOW, and go actually
> >> > read (or re-read) the documents in question.
> >> 
> >> For GS2, I think binary isn't an unreasonable choice, and I agree with
> >> you.  I also think that there is some merit to having textual protocols,
> >> and I think making our DIGEST-MD5 successor textual would be nice.
> >
> > There's very little binary anything in GS2:
> >
> >  - two 32-bit unsigned network byte order lengths
> >  - another 32-bit quantity: maxbuf for security layers
> >  - a pair of one-byte flags for security layer and channel-binding
> >    negotiation
> >  - the actual GSS-API mechanism tokens in the authentication exchanges
> >
> > Base64-encoding the GSS tokens would allow us to get rid of those two
> > lengths; the flags and the maxbuf can be expressed textually.
> 
> That is true, and getting rid of the length fields would be neat.  But
> if we are holding GS2, I suspect GS2 will be radically different when/if
> brought back from its zombie state.  I'm not sure it makes sense to
> spend time at this point to re-work the protocol for a technically small
> change like this, when we may be doing larger changes later on.

I'm not done writing up the SCRAM+GS2 ABNF and related text.  After I
post that hopefully Chris and others will agree that it's not overly
complex, or perhaps they'll insist on making the changes I mention
above and then they'll find it agreeable.  That will get GS2 "unheld."



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IMNqC1010565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 15:23:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IMNquo010564; Tue, 18 Mar 2008 15:23:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IMNo96010556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 15:23:51 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IMNb0g013148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 23:23:37 +0100
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Chris Newman <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 18 Mar 2008 17:05:46 -0500")
References: <44ADB860B3FF5E9FF13784B6@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::4+uUmMuQ4Kncqi0Q:0TQG
X-Hashcash: 1:22:080318:[e-mail]::VfdyXkB7UrDoNEw8:BlL7
X-Hashcash: 1:22:080318:[e-mail]::iOS7gQqV6H+LnErS:I4Ph
X-Hashcash: 1:22:080318:[e-mail]::yFm09n2cw9/cGNVM:duRR
Date: Tue, 18 Mar 2008 23:23:37 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Mar 18, 2008 at 10:47:37PM +0100, Simon Josefsson wrote:
>> Jeffrey Hutzelman <[e-mail]> writes:
>> > I'm seeing an awful lot of "GS2 is going to make the wire encoding more
>> > complicated!  It's binary; binary is always complicated!" and similar FUD.
>> > I really wish people would stop spreading that, RIGHT NOW, and go actually
>> > read (or re-read) the documents in question.
>> 
>> For GS2, I think binary isn't an unreasonable choice, and I agree with
>> you.  I also think that there is some merit to having textual protocols,
>> and I think making our DIGEST-MD5 successor textual would be nice.
>
> There's very little binary anything in GS2:
>
>  - two 32-bit unsigned network byte order lengths
>  - another 32-bit quantity: maxbuf for security layers
>  - a pair of one-byte flags for security layer and channel-binding
>    negotiation
>  - the actual GSS-API mechanism tokens in the authentication exchanges
>
> Base64-encoding the GSS tokens would allow us to get rid of those two
> lengths; the flags and the maxbuf can be expressed textually.

That is true, and getting rid of the length fields would be neat.  But
if we are holding GS2, I suspect GS2 will be radically different when/if
brought back from its zombie state.  I'm not sure it makes sense to
spend time at this point to re-work the protocol for a technically small
change like this, when we may be doing larger changes later on.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IM5mvf008435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 15:05:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IM5mVU008434; Tue, 18 Mar 2008 15:05:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IM5lvQ008427 for <[e-mail]>; Tue, 18 Mar 2008 15:05:48 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2IM5lTJ028947 for <[e-mail]>; Tue, 18 Mar 2008 22:05:47 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IM5kAl032822 for <[e-mail]>; Tue, 18 Mar 2008 16:05:47 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IM5kxN018579; Tue, 18 Mar 2008 17:05:46 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IM5kpn018578; Tue, 18 Mar 2008 17:05:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 17:05:46 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Chris Newman <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Chris Newman <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
References: <44ADB860B3FF5E9FF13784B6@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 10:47:37PM +0100, Simon Josefsson wrote:
> Jeffrey Hutzelman <[e-mail]> writes:
> > I'm seeing an awful lot of "GS2 is going to make the wire encoding more
> > complicated!  It's binary; binary is always complicated!" and similar FUD.
> > I really wish people would stop spreading that, RIGHT NOW, and go actually
> > read (or re-read) the documents in question.
> 
> For GS2, I think binary isn't an unreasonable choice, and I agree with
> you.  I also think that there is some merit to having textual protocols,
> and I think making our DIGEST-MD5 successor textual would be nice.

There's very little binary anything in GS2:

 - two 32-bit unsigned network byte order lengths
 - another 32-bit quantity: maxbuf for security layers
 - a pair of one-byte flags for security layer and channel-binding
   negotiation
 - the actual GSS-API mechanism tokens in the authentication exchanges

Base64-encoding the GSS tokens would allow us to get rid of those two
lengths; the flags and the maxbuf can be expressed textually.

The GSS tokens in the _security layers_ would not need to be base64-
encoded -- that stuff (like the application plain-text) can be binary
and noone will mind.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ILls3d006812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 14:47:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ILlsCx006811; Tue, 18 Mar 2008 14:47:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ILlnrw006804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 14:47:53 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2ILlbsx007484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 22:47:38 +0100
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Chris Newman <[e-mail]>, Tom Yu <[e-mail]>, <[e-mail]>
Subject: Re: which is our DIGEST-MD5 successor?
References: <44ADB860B3FF5E9FF13784B6@446E7922C82D299DB29D899F> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::4JS1J5YvPCiiMHBb:0Wn
X-Hashcash: 1:22:080318:[e-mail]::zBDxNIxDG33qIHEw:Buln
X-Hashcash: 1:22:080318:[e-mail]::6ACjn6bjNbJtDq3O:ACxO
X-Hashcash: 1:22:080318:[e-mail]::wsEpU4hlyGpdMwmz:hsJK
Date: Tue, 18 Mar 2008 22:47:37 +0100
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Wed, 12 Mar 2008 13:53:03 -0400 (EDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

>> While I prefer to avoid two different wire encodings for the same
> function,
>> I consider the deployability of the mechanism to be a much more important
>> concern and the deployment impact of binary in the SASL authentication
>> protocol is significant in my experience.
>
> Let us please be clear.  SASL is not a text-based.  SASL is binary.
> SASL-using application protocols may be text-based, and this often
> requires them to hex- or base64-encode SASL messages.  You are not going
> to be able to look at the bits on the wire and debug a SASL mechanism,
> especially in the text-based protocols that are its major users, without
> some decoding assistance.
>
> For example, IMAP's AUTHENTICATE command exchanges base64-encoded tokens;
> this means that you cannot read SCRAM's semi-human-readable tokens in a
> packet trace.
>
> SMTP's AUTH command behaves the same way.

In fairness, I've done a fair amount of SASL authentication debugging
using only a base64 decoder (e.g., emacs), and every time I have been
grateful that the protocol was textual rather than binary, even though I
had to by-pass the initial base64 obfuscation.

> I'm seeing an awful lot of "GS2 is going to make the wire encoding more
> complicated!  It's binary; binary is always complicated!" and similar FUD.
> I really wish people would stop spreading that, RIGHT NOW, and go actually
> read (or re-read) the documents in question.

For GS2, I think binary isn't an unreasonable choice, and I agree with
you.  I also think that there is some merit to having textual protocols,
and I think making our DIGEST-MD5 successor textual would be nice.

/Simon




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ILfWLe006486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 14:41:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ILfWQt006485; Tue, 18 Mar 2008 14:41:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ILfR2c006470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 14:41:31 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2ILfKlk007029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 22:41:20 +0100
From: Simon Josefsson <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 18 Mar 2008 15:21:20 -0500")
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::UHk596Z+BVvysxyo:2z2I
X-Hashcash: 1:22:080318:[e-mail]::IHA6jG82Mdef2sQL:0Mc4
X-Hashcash: 1:22:080318:[e-mail]::h7fgMYzBozTcaJ31:3rs7
Date: Tue, 18 Mar 2008 22:41:20 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Mar 18, 2008 at 08:41:46PM +0100, Hallvard B Furuseth wrote:
>> Simon Josefsson writes:
>> > 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 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.)

Yes.

>> 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.
>
> Right, we'd have to say that the server must also store both sets of
> verifiers and credentials.

Yes, I meant that too.

>> You can say that clients MUST support both and servers MAY support
>> either.
>
> 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.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ILNGP3004900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 14:23:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ILNGcN004899; Tue, 18 Mar 2008 14:23:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ILNE42004887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 14:23:15 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JbjH3-0006hQ-KX; Tue, 18 Mar 2008 22:23:09 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx8.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JbjBo-0004Rt-RB; Tue, 18 Mar 2008 22:17:44 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JbjBo-0004Wf-NW; Tue, 18 Mar 2008 22:17:44 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 22:17:44 +0100
To: Nicolas Williams <[e-mail]>
cc: Simon Josefsson <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 503BA3398941E550820F7EBA56247CFDFC3A5B69
X-UiO-SR-test: 572090D7EEB391ECB47F8EBF158695324887B02E
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 561 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wrote:
> 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.

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

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IKtHbq001582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 13:55:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IKtHRw001581; Tue, 18 Mar 2008 13:55:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IKtFWD001574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 13:55:16 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jbiq0-0000MO-Ih; Tue, 18 Mar 2008 21:55:12 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jbiq0-00034c-3D; Tue, 18 Mar 2008 21:55:12 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1Jbipz-0004F4-V8; Tue, 18 Mar 2008 21:55:11 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 21:55:11 +0100
To: Nicolas Williams <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 08E2EDF2D72D813E4843586AC241E3BE70A2D0BA
X-UiO-SR-test: C611937B2D760DB2E21ED770431E04234DBCA040
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 559 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams writes:
>On Tue, Mar 18, 2008 at 08:41:46PM +0100, Hallvard B Furuseth wrote:
>>Simon Josefsson writes:
>>> 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 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.)
>
>> 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.
>
> Right, we'd have to say that the server must also store both sets of
> 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.

>> You can say that clients MUST support both and servers MAY support
>> either.
>
> 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.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IKNPQJ098579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 13:23:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IKNPA4098578; Tue, 18 Mar 2008 13:23:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IKNOoN098571 for <[e-mail]>; Tue, 18 Mar 2008 13:23:25 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2IKNO9i004530 for <[e-mail]>; Tue, 18 Mar 2008 20:23:24 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IKNOEi025741 for <[e-mail]>; Tue, 18 Mar 2008 14:23:24 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IKNOJP018396; Tue, 18 Mar 2008 15:23:24 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IKNOLt018395; Tue, 18 Mar 2008 15:23:24 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 15:23:24 -0500
From: Nicolas Williams <[e-mail]>
To: Frank Ellermann <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Frank Ellermann <[e-mail]>, [e-mail]
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <froqjb$3v2$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <froqjb$3v2$[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 05:31:05PM +0100, Frank Ellermann wrote:
> 
> Simon Josefsson wrote:
> 
> > I think our choice should be between HMAC-SHA-1 and HMAC-SHA-256.
> 
> I'll ignore it then.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IKLMqG098358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 13:21:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IKLMBp098357; Tue, 18 Mar 2008 13:21:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IKLL47098349 for <[e-mail]>; Tue, 18 Mar 2008 13:21:22 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2IKLLKl028123 for <[e-mail]>; Tue, 18 Mar 2008 20:21:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IKLKVU024323 for <[e-mail]>; Tue, 18 Mar 2008 14:21:21 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IKLKMn018389; Tue, 18 Mar 2008 15:21:20 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IKLKUL018388; Tue, 18 Mar 2008 15:21:20 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 15:21:20 -0500
From: Nicolas Williams <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Hallvard B Furuseth <[e-mail]>, Simon Josefsson <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 08:41:46PM +0100, Hallvard B Furuseth wrote:
> Simon Josefsson writes:
> > 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 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.)

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

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IJftpD094226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 12:41:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IJftpC094225; Tue, 18 Mar 2008 12:41:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IJfpRb094214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 12:41:54 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jbhgx-0000uG-G7; Tue, 18 Mar 2008 20:41:47 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx8.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jbhgx-0004MC-34; Tue, 18 Mar 2008 20:41:47 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1Jbhgw-0007Uz-Uk; Tue, 18 Mar 2008 20:41:46 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 20:41:46 +0100
To: Simon Josefsson <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 051336616E21FE318E3E3688A5B998C899E52404
X-UiO-SR-test: F34D6F61F237D27E22A0DEDCE7E5C6822768F461
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 1 bait 0 mail/h: 1 total 558 max/h 5 blacklist 0 greylist 1 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> 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 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IJJR20091962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 12:19:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IJJRui091961; Tue, 18 Mar 2008 12:19:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IJJOiY091949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 12:19:26 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IJJGI4021460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 20:19:17 +0100
From: Simon Josefsson <[e-mail]>
To: Frank Ellermann <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::WC5STebYVi2l5ix5:5bKM
X-Hashcash: 1:22:080318:[e-mail]::9rDGXz3CaawP8AvU:V+1Z
Date: Tue, 18 Mar 2008 20:19:16 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 18 Mar 2008 13:25:11 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Mar 18, 2008 at 06:38:45PM +0100, Simon Josefsson wrote:
>> 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.
>
> 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.

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

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

Sure.

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

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 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.
>
> I can agree with that.  I don't think Chriss will like that answer
> though.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIPDx5086013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 11:25:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IIPDfu086009; Tue, 18 Mar 2008 11:25:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIPCGJ085998 for <[e-mail]>; Tue, 18 Mar 2008 11:25:12 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2IIPBT3022670 for <[e-mail]>; Tue, 18 Mar 2008 18:25:12 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IIPBsf035326 for <[e-mail]>; Tue, 18 Mar 2008 12:25:11 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IIPBof018156; Tue, 18 Mar 2008 13:25:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IIPBG9018155; Tue, 18 Mar 2008 13:25:11 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 13:25:11 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 06:38:45PM +0100, Simon Josefsson wrote:
> 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.

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.

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

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.

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIHQX3085539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 11:17:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IIHQIb085538; Tue, 18 Mar 2008 11:17:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIHPcw085531 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 11:17:25 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2IIHPf3019253 for <[e-mail]>; Tue, 18 Mar 2008 18:17:25 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IIHP4S028079 for <[e-mail]>; Tue, 18 Mar 2008 12:17:25 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IIHP7m018144; Tue, 18 Mar 2008 13:17:25 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IIHOEe018143; Tue, 18 Mar 2008 13:17:24 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 13:17:24 -0500
From: Nicolas Williams <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
Mail-Followup-To: Hallvard B Furuseth <[e-mail]>, Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 06:42:54PM +0100, Hallvard B Furuseth wrote:
> 
> Simon Josefsson writes:
> > I'm not strongly opposed to realms, but if it leads to complexity in the
> > 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?

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIFpIx085146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 11:15:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IIFppg085145; Tue, 18 Mar 2008 11:15:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIFoS5085137 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 11:15:51 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2IIFmSp018295 for <[e-mail]>; Tue, 18 Mar 2008 18:15:50 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IIFlHf026352 for <[e-mail]>; Tue, 18 Mar 2008 12:15:47 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IIFiTJ018137; Tue, 18 Mar 2008 13:15:44 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IIFhSe018136; Tue, 18 Mar 2008 13:15:43 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 13:15:43 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 06:21:44PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > 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).
> 
> If I understand your scenario, it may be that it can be solved easily
> with unmodified SCRAM, see my response to Jeff.

If you mean this:

> >> 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 '[e-mail]', '[e-mail]' for each of the
> >> servers in that realm.  The enrollment process could push out the
> >> password-equivalent hash to each server.
> >
> > Ick.
> 
> 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.

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.

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

> >> In my experience, the realms feature was not used widely with
> >> DIGEST-MD5, but made the specification more complex.
> >
> > 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
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHr4WB081800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:53:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHr4XK081798; Tue, 18 Mar 2008 10:53:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHr2QE081790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 10:53:03 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IHqtML004533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 18:52:55 +0100
From: Simon Josefsson <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::o/lkTwH7KAtG0jcf:1U57
X-Hashcash: 1:22:080318:[e-mail]::s1zQnsYU5lMtZ1UC:2R6G
X-Hashcash: 1:22:080318:[e-mail]::jH0+wp2pFReiwyn3:Q0Zv
Date: Tue, 18 Mar 2008 18:52:55 +0100
In-Reply-To: <[e-mail]> (Hallvard B. Furuseth's message of "Tue, 18 Mar 2008 18:42:54 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth <[e-mail]> writes:

> Simon Josefsson writes:
>> I'm not strongly opposed to realms, but if it leads to complexity in the
>> 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.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHoUeA081622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:50:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHoU6C081621; Tue, 18 Mar 2008 10:50:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHoP0r081594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 10:50:28 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jbfx9-0004kL-F5 for [e-mail]; Tue, 18 Mar 2008 17:50:23 +0000
Received: from hmbg-d9b88e27.pool.mediaways.net ([217.184.142.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 17:50:23 +0000
Received: from nobody by hmbg-d9b88e27.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 17:50:23 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Date:  Tue, 18 Mar 2008 18:52:53 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 29
Message-ID: <frovcn$n2s$[e-mail]>
References:  <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <frnsiu$5a6$[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e27.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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) =3D H(Hi-1(x))
should be "better" than Hi(x) =3D 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.  =20

Without examples RFC 2898 is not interesting for=20
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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHgwbW081051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:42:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHgwda081050; Tue, 18 Mar 2008 10:42:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHgukp081043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 10:42:57 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jbfpv-0000N2-0D; Tue, 18 Mar 2008 18:42:55 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jbfpu-0001SK-Kw; Tue, 18 Mar 2008 18:42:54 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1Jbfpu-0006M4-Iy; Tue, 18 Mar 2008 18:42:54 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 18:42:54 +0100
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 22BFF1AAA3D0D947AD66EFD808C0B2E226827221
X-UiO-SR-test: D831F1F797E4E6EBC68037920A2C870AA37FB576
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 4 total 557 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> I'm not strongly opposed to realms, but if it leads to complexity in the
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHcsRc080593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:38:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHcsZX080592; Tue, 18 Mar 2008 10:38:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHcpfQ080584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 10:38:53 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IHcj5C003046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 18:38:45 +0100
From: Simon Josefsson <[e-mail]>
To: Frank Ellermann <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::cTf8YoKalczPVeR1:Hch6
X-Hashcash: 1:22:080318:[e-mail]::2FNYEu7r7eYeVSTq:LAdb
Date: Tue, 18 Mar 2008 18:38:45 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 18 Mar 2008 11:09:59 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHM9Ci079088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:22:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHM96F079087; Tue, 18 Mar 2008 10:22:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHM7Um079078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 10:22:09 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IHLiKE031609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 18:21:45 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 18 Mar 2008 11:14:10 -0500")
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::Zi0pDE4UwLXGhr36:B4Du
X-Hashcash: 1:22:080318:[e-mail]::pWDiPsAGhDa/gimS:KslQ
Date: Tue, 18 Mar 2008 18:21:44 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Mar 18, 2008 at 04:52:49PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > Not being able to enroll once but authenticate to many servers seems
>> > obnoxious.
>> 
>> 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.
>
> 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).

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

>> 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 '[e-mail]', '[e-mail]' for each of the
>> servers in that realm.  The enrollment process could push out the
>> password-equivalent hash to each server.
>
> Ick.

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.

>> In my experience, the realms feature was not used widely with
>> DIGEST-MD5, but made the specification more complex.
>
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHFeWL078564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:15:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHFe1j078563; Tue, 18 Mar 2008 10:15:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHFbHq078544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 10:15:39 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IHFHiG028972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 18:15:18 +0100
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Tue, 18 Mar 2008 12:07:14 -0400")
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::CxPvKH7Ar4i1Gihg:2WS3
X-Hashcash: 1:22:080318:[e-mail]::lTd9w+m8Zc/md6qj:EwL+
X-Hashcash: 1:22:080318:[e-mail]::RFhkRwTBU9pmfS3M:Htwd
Date: Tue, 18 Mar 2008 18:15:17 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Tuesday, March 18, 2008 04:52:49 PM +0100 Simon Josefsson
> <[e-mail]> wrote:
>
>> 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.
>
> 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.
>
>> 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 '[e-mail]', '[e-mail]' for each of the
>> servers in that realm.  The enrollment process could push out the
>> 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.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHFdgQ078552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:15:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHFdc7078551; Tue, 18 Mar 2008 10:15:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHFb2t078543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 10:15:38 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JbfPR-0002WP-3x; Tue, 18 Mar 2008 18:15:33 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JbfPQ-0000SX-Qg; Tue, 18 Mar 2008 18:15:32 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JbfPQ-000667-Nz; Tue, 18 Mar 2008 18:15:32 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 18:15:32 +0100
To: Nicolas Williams <[e-mail]>
cc: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 91632D7048F3DE204BEBDAE7ACF409877F3FB96A
X-UiO-SR-test: 6247E1BF2E9BA8A6F28A7A91F6369C34FFA92D54
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 555 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wrote:
> 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

sorry,   for that _user_ of course.

> first place.

Though I notice Tony has already answered anyway.

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IH1F49076606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:01:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IH1Fbg076605; Tue, 18 Mar 2008 10:01:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IH1CRE076592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 10:01:14 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JbfBW-0007uE-VF; Tue, 18 Mar 2008 18:01:11 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx8.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JbfBW-0007BN-Er; Tue, 18 Mar 2008 18:01:10 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JbfBW-0005wz-BW; Tue, 18 Mar 2008 18:01:10 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 18:01:10 +0100
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 335D88B17971FB3112E592CB22D074FF1A995856
X-UiO-SR-test: E0C64F8F26DB2D8091DF12F7A2EA0280FE25D65A
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 1 bait 0 mail/h: 1 total 554 max/h 5 blacklist 0 greylist 1 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams writes:
>On Tue, Mar 18, 2008 at 03:31:03PM +0100, Hallvard B Furuseth wrote:
>>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.
>
> 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.

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.

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

Yes...

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

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.

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

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

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.

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGp7IH074895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:51:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IGp7jQ074894; Tue, 18 Mar 2008 09:51:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGp32v074885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 09:51:06 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2IGp1Vp017732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 12:51:01 -0400 (EDT)
Date: Tue, 18 Mar 2008 12:51:01 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Frank Ellermann <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <frnsiu$5a6$[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>
> On Tue, Mar 18, 2008 at 08:27:08AM +0100, Frank Ellermann wrote:
>> Chris Newman wrote:
>> > 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.
>
> 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.
>
>> > It may be not a lot of complexity, but every
>> > bit matters.
>>
>> I'm more interested in nanoseconds than in bits,
>> 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.
>
>> > 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
>
> MD5 is much more a dead end than SHA-1.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGTvOi071940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:29:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IGTves071939; Tue, 18 Mar 2008 09:29:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGTudm071933 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 09:29:57 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2IGTt9l017447 for <[e-mail]>; Tue, 18 Mar 2008 16:29:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IGTt7W062180 for <[e-mail]>; Tue, 18 Mar 2008 10:29:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IGTtxN018105; Tue, 18 Mar 2008 11:29:55 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IGTtgd018104; Tue, 18 Mar 2008 11:29:55 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 11:29:55 -0500
From: Nicolas Williams <[e-mail]>
To: Tony Finch <[e-mail]>
Cc: Hallvard B Furuseth <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Tony Finch <[e-mail]>, Hallvard B Furuseth <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 04:21:49PM +0000, Tony Finch wrote:
> On Tue, 18 Mar 2008, Nicolas Williams wrote:
> > 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?
> 
> 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.

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

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGSiaB071840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:28:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IGSifb071839; Tue, 18 Mar 2008 09:28:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGSeVN071826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 09:28:42 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jbeg3-0000dI-9v for [e-mail]; Tue, 18 Mar 2008 16:28:39 +0000
Received: from hmbg-d9b88e27.pool.mediaways.net ([217.184.142.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 16:28:39 +0000
Received: from nobody by hmbg-d9b88e27.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 16:28:39 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Date:  Tue, 18 Mar 2008 17:31:05 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 6
Message-ID: <froqjb$3v2$[e-mail]>
References:  <[e-mail]> <frmdmk$h1o$[e-mail]><[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e27.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

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

I'll ignore it then.
 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGMNOo071078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:22:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IGMNK8071077; Tue, 18 Mar 2008 09:22:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGMLw2071051 for <[e-mail]>; Tue, 18 Mar 2008 09:22:22 -0700 (MST) (envelope-from [e-mail])
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58241) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1JbeZR-0003hW-Ih (Exim 4.67) (return-path <[e-mail]>); Tue, 18 Mar 2008 16:21:49 +0000
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1JbeZR-00048i-P5 (Exim 4.67) (return-path <[e-mail]>); Tue, 18 Mar 2008 16:21:49 +0000
Date: Tue, 18 Mar 2008 16:21:49 +0000
From: Tony Finch <[e-mail]>
X-X-Sender: [e-mail]
To: Nicolas Williams <[e-mail]>
cc: Hallvard B Furuseth <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.00 (LSU 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 18 Mar 2008, Nicolas Williams wrote:
>
> 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?

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.

> > 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.
>
> 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  <[e-mail]>  http://dotat.at/
MALIN HEBRIDES: MAINLY NORTH OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT OR
MODERATE, OCCASIONALLY ROUGH. SHOWERS. GOOD.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGLhn9070928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:21:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IGLhQi070926; Tue, 18 Mar 2008 09:21:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGLg6K070919 for <[e-mail]>; Tue, 18 Mar 2008 09:21:43 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2IGLggh027214 for <[e-mail]>; Tue, 18 Mar 2008 16:21:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IGLfQu045752 for <[e-mail]>; Tue, 18 Mar 2008 10:21:42 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IGLfKI018089; Tue, 18 Mar 2008 11:21:41 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IGLfxJ018088; Tue, 18 Mar 2008 11:21:41 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 11:21:41 -0500
From: Nicolas Williams <[e-mail]>
To: Frank Ellermann <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Frank Ellermann <[e-mail]>, [e-mail]
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <frnsiu$5a6$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <frnsiu$5a6$[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 08:27:08AM +0100, Frank Ellermann wrote:
> Chris Newman wrote:
> > 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.

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.

> > It may be not a lot of complexity, but every 
> > bit matters.
> 
> I'm more interested in nanoseconds than in bits,
> 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.

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

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

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGEBMH069973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:14:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IGEBoM069972; Tue, 18 Mar 2008 09:14:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGEADk069966 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 09:14:11 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2IGEAPU010527 for <[e-mail]>; Tue, 18 Mar 2008 16:14:10 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IGEACr038200 for <[e-mail]>; Tue, 18 Mar 2008 10:14:10 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IGEAD9018076; Tue, 18 Mar 2008 11:14:10 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IGEAYZ018075; Tue, 18 Mar 2008 11:14:10 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 11:14:10 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 04:52:49PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > Not being able to enroll once but authenticate to many servers seems
> > obnoxious.
> 
> 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.

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

> 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 '[e-mail]', '[e-mail]' for each of the
> servers in that realm.  The enrollment process could push out the
> password-equivalent hash to each server.

Ick.

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

OK, I withdraw this proposal.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGAEOD069294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:10:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IGAETv069293; Tue, 18 Mar 2008 09:10:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IGA2sn069265 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 09:10:02 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2IG9xrr021332 for <[e-mail]>; Tue, 18 Mar 2008 16:10:01 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IG9x5Z032805 for <[e-mail]>; Tue, 18 Mar 2008 10:09:59 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IG9xGZ018069; Tue, 18 Mar 2008 11:09:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IG9xSP018068; Tue, 18 Mar 2008 11:09:59 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 11:09:59 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 04:40:03PM +0100, Simon Josefsson wrote:
> I think our choice should be between HMAC-SHA-1 and HMAC-SHA-256.  I

I agree.

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IG7K4h069002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:07:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IG7KUV069001; Tue, 18 Mar 2008 09:07:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IG7Itd068913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 09:07:19 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2IG7Es2015034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 12:07:14 -0400 (EDT)
Date: Tue, 18 Mar 2008 12:07:14 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, March 18, 2008 04:52:49 PM +0100 Simon Josefsson 
<[e-mail]> wrote:

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

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.

> 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 '[e-mail]', '[e-mail]' for each of the
> servers in that realm.  The enrollment process could push out the
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IG4Fbl068494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 09:04:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IG4F3Z068492; Tue, 18 Mar 2008 09:04:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IG4Evl068486 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 09:04:14 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2IG4D83005838 for <[e-mail]>; Tue, 18 Mar 2008 16:04:13 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2IG4DOu026825 for <[e-mail]>; Tue, 18 Mar 2008 10:04:13 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2IG4DD7018060; Tue, 18 Mar 2008 11:04:13 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2IG4Dpk018059; Tue, 18 Mar 2008 11:04:13 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Mar 2008 11:04:13 -0500
From: Nicolas Williams <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Hallvard B Furuseth <[e-mail]>, Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 03:31:03PM +0100, Hallvard B Furuseth wrote:
> 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.

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

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

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

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

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.

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IFqwHu067590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 08:52:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IFqwKN067589; Tue, 18 Mar 2008 08:52:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IFquGM067583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 08:52:57 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IFqnA3016220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 16:52:50 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::Ms1Pth/YQpdXFuhc:B4KZ
X-Hashcash: 1:22:080318:[e-mail]::39M+VwnmcjtbL0pH:CqGK
Date: Tue, 18 Mar 2008 16:52:49 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 17 Mar 2008 21:35:27 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, Mar 17, 2008 at 05:56:44PM -0700, Chris Newman wrote:
>> 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., [e-mail] 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.

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 '[e-mail]', '[e-mail]' 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IFeFtW066259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 08:40:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IFeFgB066258; Tue, 18 Mar 2008 08:40:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IFeC2X066249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Mar 2008 08:40:14 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2IFe3g1014500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 16:40:04 +0100
From: Simon Josefsson <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <frnouh$se3$[e-mail]> (Frank Ellermann's message of "Tue, 18 Mar 2008 07:56:47 +0100")
References: <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]> <frnouh$se3$[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::5e3q26iOTdTymFGE:1cdh
X-Hashcash: 1:22:080318:[e-mail]::gbYU+3DcH9M7iVkw:ACQP
Date: Tue, 18 Mar 2008 16:40:03 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Frank Ellermann" <[e-mail]> writes:

>> SHA-1 is not covered by the SHA-2 patent as far as
>> I have understood.
>
> 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.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IEVBIA058598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 07:31:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IEVAtt058597; Tue, 18 Mar 2008 07:31:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IEV8HA058587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 07:31:10 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JbcqI-0000eR-Hn; Tue, 18 Mar 2008 15:31:06 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1JbcqF-0008UK-Vf; Tue, 18 Mar 2008 15:31:04 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JbcqF-0004XF-KK; Tue, 18 Mar 2008 15:31:03 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 18 Mar 2008 15:31:03 +0100
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]>
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 8094B22134766866A76EE9150BB97788D0F4A721
X-UiO-SR-test: FFEC9B6C25933F893A35C67E659A895EAEC786AF
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 553 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I7uVHn002547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 00:56:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I7uVoa002545; Tue, 18 Mar 2008 00:56:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I7uQ0m002532 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 00:56:28 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbWgK-0008Q8-Id for [e-mail]; Tue, 18 Mar 2008 07:56:24 +0000
Received: from hmbg-d9b88e27.pool.mediaways.net ([217.184.142.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 07:56:24 +0000
Received: from nobody by hmbg-d9b88e27.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 07:56:24 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Date:  Tue, 18 Mar 2008 08:27:08 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 45
Message-ID: <frnsiu$5a6$[e-mail]>
References:  <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e27.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

+1
=20
> 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=20
> bit matters.

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

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I6sVRc093391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 23:54:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I6sV2v093390; Mon, 17 Mar 2008 23:54:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I6sPdm093377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Mar 2008 23:54:29 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbViG-00065w-1k for [e-mail]; Tue, 18 Mar 2008 06:54:20 +0000
Received: from hmbg-d9b88e27.pool.mediaways.net ([217.184.142.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 06:54:20 +0000
Received: from nobody by hmbg-d9b88e27.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 18 Mar 2008 06:54:20 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Date:  Tue, 18 Mar 2008 07:56:47 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 17
Message-ID: <frnouh$se3$[e-mail]>
References:  <[e-mail]> <frmdmk$h1o$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e27.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.
=20
> SHA-1 is not covered by the SHA-2 patent as far as
> I have understood.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I31cT2068300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 20:01:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I31c0v068299; Mon, 17 Mar 2008 20:01:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I31aa0068282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Mar 2008 20:01:37 -0700 (MST) (envelope-from [e-mail])
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 8B5C42611989 for <[e-mail]>; Mon, 17 Mar 2008 20:01:36 -0700 (PDT)
Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 75A4C28042 for <[e-mail]>; Mon, 17 Mar 2008 20:01:36 -0700 (PDT)
X-AuditID: 1180711d-ad703bb0000008fb-bc-47df3090a437
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay13.apple.com (Apple SCV relay) with ESMTP id 5526E28041 for <[e-mail]>; Mon, 17 Mar 2008 20:01:36 -0700 (PDT)
Received: from [192.168.1.201] (adsl-75-18-160-61.dsl.pltn13.sbcglobal.net [75.18.160.61]) by et.apple.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 17 Mar 2008 20:01:36 -0700 (PDT)
Date: Mon, 17 Mar 2008 20:01:34 -0700
From: Steven Simon <[e-mail]>
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
In-reply-to: <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.919.2)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]>
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:

>
> On Mon, Mar 17, 2008 at 05:56:44PM -0700, Chris Newman wrote:
>> 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., [e-mail] 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
> -- 
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I2oLJM067081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 19:50:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I2oKrv067080; Mon, 17 Mar 2008 19:50:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I2oK56067069 for <[e-mail]>; Mon, 17 Mar 2008 19:50:20 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2I2oJ9p011934 for <[e-mail]>; Tue, 18 Mar 2008 02:50:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2I2oJIo016126 for <[e-mail]>; Mon, 17 Mar 2008 20:50:19 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2I2oJd2017918; Mon, 17 Mar 2008 21:50:19 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2I2oJJC017917; Mon, 17 Mar 2008 21:50:19 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 17 Mar 2008 21:50:19 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 18, 2008 at 02:20:31AM +0100, Simon Josefsson wrote:
> 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?

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I2nDtN066951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 19:49:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I2nDMV066950; Mon, 17 Mar 2008 19:49:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I2nCq3066943 for <[e-mail]>; Mon, 17 Mar 2008 19:49:13 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2I2nCq1003633 for <[e-mail]>; Tue, 18 Mar 2008 02:49:12 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2I2nBm9015445 for <[e-mail]>; Mon, 17 Mar 2008 20:49:11 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2I2nBKx017909; Mon, 17 Mar 2008 21:49:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2I2nBxP017908; Mon, 17 Mar 2008 21:49:11 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 17 Mar 2008 21:49:11 -0500
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 17, 2008 at 05:48:14PM -0700, Chris Newman wrote:
> 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.

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

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

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.

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

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

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I2ZTpM065651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 19:35:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I2ZTwx065650; Mon, 17 Mar 2008 19:35:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I2ZSoA065644 for <[e-mail]>; Mon, 17 Mar 2008 19:35:29 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2I2ZS6W028339 for <[e-mail]>; Tue, 18 Mar 2008 02:35:28 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2I2ZSfI008102 for <[e-mail]>; Mon, 17 Mar 2008 20:35:28 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2I2ZS8N017898; Mon, 17 Mar 2008 21:35:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2I2ZRh6017897; Mon, 17 Mar 2008 21:35:27 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 17 Mar 2008 21:35:27 -0500
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
Mail-Followup-To: Chris Newman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 17, 2008 at 05:56:44PM -0700, Chris Newman wrote:
> 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., [e-mail] 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
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I1KboX058226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 18:20:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I1Kbds058225; Mon, 17 Mar 2008 18:20:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I1KYaQ058216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Mar 2008 18:20:36 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2I1KV9B030935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 02:20:31 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
References: <[e-mail]> <[e-mail]> <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::rpglI4Cu9wX/ZMI0:19J1
X-Hashcash: 1:22:080318:[e-mail]::By+Ge4ebZ3ywgSC9:LSxT
X-Hashcash: 1:22:080318:[e-mail]::uzvIhZej5U8bnJSQ:jM5l
Date: Tue, 18 Mar 2008 02:20:31 +0100
In-Reply-To: <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 17 Mar 2008 17:56:44 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]> writes:

> 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., [e-mail] as my login identifier).
>
> 		- Chris
>
> --On March 17, 2008 12:13:18 -0500 Nicolas Williams
> <[e-mail]> wrote:
>
>>
>> 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).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I1CsjS057392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 18:12:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I1Csg8057391; Mon, 17 Mar 2008 18:12:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I1CpU5057377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Mar 2008 18:12:53 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2I1Cmur029179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 02:12:48 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
References: <[e-mail]> <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080318:[e-mail]::110H356w9V5gqZRr:QPnj
X-Hashcash: 1:22:080318:[e-mail]::aayDlDh4yc+qrABo:XXK2
Date: Tue, 18 Mar 2008 02:12:48 +0100
In-Reply-To: <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 17 Mar 2008 17:48:14 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I0uG2u055953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 17:56:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I0uG4V055952; Mon, 17 Mar 2008 17:56:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I0uGTh055946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 17 Mar 2008 17:56:16 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2I0uF8f015994 for <[e-mail]>; Mon, 17 Mar 2008 17:56:16 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 17 Mar 2008 17:56:15 -0700 (PDT)
Received: from [10.0.1.4] ([10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Mon, 17 Mar 2008 17:56:15 -0700 (PDT)
Date: Mon, 17 Mar 2008 17:56:44 -0700
From: Chris Newman <[e-mail]>
Subject: Re: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
In-reply-to: <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
Cc: [e-mail]
Message-id: <77D15A421FF0FC423FF1A61C@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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., [e-mail] as my login identifier).

		- Chris

--On March 17, 2008 12:13:18 -0500 Nicolas Williams 
<[e-mail]> wrote:

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I0loqi055321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 17:47:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2I0loOm055320; Mon, 17 Mar 2008 17:47:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2I0lmLt055314 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 17 Mar 2008 17:47:49 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2I0lmen015484 for <[e-mail]>; Mon, 17 Mar 2008 17:47:48 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 17 Mar 2008 17:47:48 -0700 (PDT)
Received: from [10.0.1.4] ([10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Mon, 17 Mar 2008 17:47:45 -0700 (PDT)
Date: Mon, 17 Mar 2008 17:48:14 -0700
From: Chris Newman <[e-mail]>
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-reply-to: <[e-mail]>
To: Simon Josefsson <[e-mail]>, [e-mail]
Message-id: <476A4D3077F1ED511CBDCFE8@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

--On March 17, 2008 17:05:31 +0100 Simon Josefsson <[e-mail]> 
wrote:

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






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNOT65048185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 16:24:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HNOT6x048184; Mon, 17 Mar 2008 16:24:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNOQ9D048178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Mar 2008 16:24:28 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HNOM0E017701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 00:24:22 +0100
From: Simon Josefsson <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <frmdmk$h1o$[e-mail]> (Frank Ellermann's message of "Mon, 17 Mar 2008 19:38:43 +0100")
References: <[e-mail]> <frmdmk$h1o$[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080317:[e-mail]::wNE7VdJ21QTJ3VVG:HinV
X-Hashcash: 1:22:080317:[e-mail]::LFCx0Xd8zCbCSCRl:xa1+
Date: Tue, 18 Mar 2008 00:24:22 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Frank Ellermann" <[e-mail]> writes:

> Simon Josefsson wrote:
>
>> 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?
>
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNBLx9046407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 16:11:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HNBLJa046406; Mon, 17 Mar 2008 16:11:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNBIbv046387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Mar 2008 16:11:20 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HNBFmr015496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Mar 2008 00:11:15 +0100
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 17 Mar 2008 12:03:41 -0500")
References: <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080317:[e-mail]::qhsnIEpbXgLhgqMt:SSrJ
Date: Tue, 18 Mar 2008 00:11:15 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, Mar 17, 2008 at 05:05:31PM +0100, Simon Josefsson wrote:
>> While thinking about merging SCRAM with my document, I thought about how
>> 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.

Great.

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

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

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

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

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HKCHAU029857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 13:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HKCHam029856; Mon, 17 Mar 2008 13:12:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HKCFrJ029824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Mar 2008 13:12:16 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-162c.ietf71.ietf.org (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2HKC5H8002383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 16:12:05 -0400 (EDT)
Date: Mon, 17 Mar 2008 16:12:05 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, March 17, 2008 12:03:41 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

>> 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.
>
> That's exactly the right thing to do.
>
>> 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.
>
> I agree, fully.

+1



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HIaK9u020830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 11:36:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HIaKMb020829; Mon, 17 Mar 2008 11:36:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HIaGKO020817 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Mar 2008 11:36:18 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbKBv-0006XA-QG for [e-mail]; Mon, 17 Mar 2008 18:36:11 +0000
Received: from hmbg-d9b88e0a.pool.mediaways.net ([217.184.142.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 17 Mar 2008 18:36:11 +0000
Received: from nobody by hmbg-d9b88e0a.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 17 Mar 2008 18:36:11 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Date:  Mon, 17 Mar 2008 19:38:43 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 15
Message-ID: <frmdmk$h1o$[e-mail]>
References:  <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e0a.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

> Thus my suggestion is to hard code the crypto algorithm in SCRAMng,
> following the simplicity of CRAM-MD5.
=20
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HHDLQY013084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 10:13:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HHDL72013083; Mon, 17 Mar 2008 10:13:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HHDK7v013074 for <[e-mail]>; Mon, 17 Mar 2008 10:13:21 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2HHDIor025072 for <[e-mail]>; Mon, 17 Mar 2008 17:13:18 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2HHDICa011709 for <[e-mail]>; Mon, 17 Mar 2008 11:13:18 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2HHDIb3017064; Mon, 17 Mar 2008 12:13:18 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2HHDIdK017063; Mon, 17 Mar 2008 12:13:18 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 17 Mar 2008 12:13:18 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Optional domain/realm for SCRAM?  (Re: Crypto agility in SCRAM + draft-josefsson-password-auth?)
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HH3omS012059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 10:03:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HH3o2e012058; Mon, 17 Mar 2008 10:03:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HH3nLJ012050 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 17 Mar 2008 10:03:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2HH3ncw026451 for <[e-mail]>; Mon, 17 Mar 2008 17:03:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2HH3mGF002485 for <[e-mail]>; Mon, 17 Mar 2008 11:03:48 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2HH3j3u017034; Mon, 17 Mar 2008 12:03:45 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2HH3fYJ017033; Mon, 17 Mar 2008 12:03:41 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 17 Mar 2008 12:03:41 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: Crypto agility in SCRAM + draft-josefsson-password-auth?
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 17, 2008 at 05:05:31PM +0100, Simon Josefsson wrote:
> While thinking about merging SCRAM with my document, I thought about how
> 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...

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

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.

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

That's exactly the right thing to do.

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

I agree, fully.

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

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.

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

Yes please.

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

Absolutely.  No more MD5 anywhere.

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

More agreement.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HG5kjr005056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 09:05:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HG5k7M005055; Mon, 17 Mar 2008 09:05:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HG5blB005031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Mar 2008 09:05:45 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2HG5VK3019221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 17 Mar 2008 17:05:32 +0100
X-Hashcash: 1:22:080317:[e-mail]::RX63VbgNTR657uyN:Dvsb
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Crypto agility in SCRAM + draft-josefsson-password-auth?
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 17 Mar 2008 17:05:31 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DDrnCF044274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 06:53:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DDrnHB044273; Thu, 13 Mar 2008 06:53:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DDrlJh044262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 13 Mar 2008 06:53:48 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZnsQ-0002gC-DD; Thu, 13 Mar 2008 14:53:46 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZnsP-0008U3-Ux; Thu, 13 Mar 2008 14:53:46 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JZnsP-0003Dr-T6; Thu, 13 Mar 2008 14:53:45 +0100
From: Hallvard B Furuseth <[e-mail]>
Message-Id: <[e-mail]>
To: Abhijit Menon-Sen <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: SCRAM-05 notes (was: Clarifying the qualities we desire the DIGEST-MD5 replacement to have)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]> <D0E775FEB1A541ADBC822D68@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Date: Thu, 13 Mar 2008 14:53:45 +0100
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 7EA778EDD30CB6FA061D363B018EC6EDF59906CF
X-UiO-SR-test: F63723108FFC91E9379CAC62B17EEDE49E15FF82
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 3 total 547 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I wrote:
>> 1.1. Terminology
>>       The authentication information for a
>>       SCRAM identity consists of salt and the "StoredKey" and
>>       "ServerKey" (as defined in the algorithm overview) for each
>>       supported cryptographic hash function.
>
> Also iteration count.  So, a set of tuples
>    (hash function, iteration count, salt, StoredKey, ServerKey).
>
> If the iteration count is a config parameter instead of stored per hash,
> the admin must throw away all hashes and get all users to set new
> passwords.

Eh.  I meant, if the admin wants to increase the configured iteration
count he must do that.


Another detail: You can use RFC 3112's authPassword for the LDAP
attribute.  Though I imagine implementations will instead use
   userPassword: {SCRAM}whatever
as described in RFC 2307, even though that breaks the LDAP standard.

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DDbQp1042399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 06:37:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DDbQPn042398; Thu, 13 Mar 2008 06:37:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DDbNnV042383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 13 Mar 2008 06:37:24 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZncV-0005zn-TX; Thu, 13 Mar 2008 14:37:20 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZncT-0003cG-7y; Thu, 13 Mar 2008 14:37:17 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JZncS-00034k-Sj; Thu, 13 Mar 2008 14:37:16 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2008 14:37:16 +0100
To: Abhijit Menon-Sen <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: SCRAM-05 notes (was: Clarifying the qualities we desire the DIGEST-MD5 replacement to have)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]> <D0E775FEB1A541ADBC822D68@446E7922C82D299DB29D899F> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: E6210650845F979FADE47F1BD500652CBB7F169D
X-UiO-SR-test: 9D291296C3C6EA40B267691E1D510E8605786D97
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 545 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Abhijit Menon-Sen writes:
>At 2008-03-12 09:33:43 -0500, [e-mail] wrote:
>>> Regarding the SCRAM draft, I hope there'll be a version soon which
>>> spells out what each challenge and response consists of, and what
>>> the server must remember (or be able to construct).  It's cumbersome
>>> to dig around in the parameter descriptions in order to figure that
>>> out.
>>
>> Agree this needs work.  I simply don't have time to be the active
>> editor on the document.
>
> I do, but I've held off working on the examples and appendices until I
> have a better understanding of what to do about GS2/GSSAPI.  (...)

Great.


Some other SCRAM notes/questions, before I forget:

> 1.1. Terminology
>       The authentication information for a
>       SCRAM identity consists of salt and the "StoredKey" and
>       "ServerKey" (as defined in the algorithm overview) for each
>       supported cryptographic hash function.

Also iteration count.  So, a set of tuples
   (hash function, iteration count, salt, StoredKey, ServerKey).

If the iteration count is a config parameter instead of stored per hash,
the admin must throw away all hashes and get all users to set new
passwords.

> 2. Introduction
>     - The server does not gain the ability to impersonate the client to
>       other servers (with an exception for server-authorized proxies).

Except to servers with the same parameters (salt, hash function,
iteration-count) for a particular hash.  (It can collect the data
clients send, like a passive eavesdropper who has stolen server-side
hashes as described in Security Considerations.)

>     - The mechanism permits the use of a server-authorized proxy without
>       requiring that proxy to have super-user rights with the back-end
>       server.

Huh?  Is this a strange way to say it supports the SASL authorization
identity field?

> 3. SCRAM Algorithm Overview
>     Similarly, the client authenticates the server by computing the
>     ServerSignature and comparing it to the value sent by the server.

Which value sent by the server?  This section forgets to mention the
final server message.

>     If the two are equal, it proves that the server had access to the
>     user's SaltedPassword.

If the client reports that they are not equal, what should the user do?
Has anything been compromised?  (If yes, the statement in the intro that
the client can authenticate the server is a bit misleading.)

> 4. SCRAM Authentication Exchange
>         C: n=Chris Newman,h=md5,r=ClientNonce
>         S: r=ClientNonceServerNonce,h=md5,s=PxR/wv+epq,i=128
>         C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
>         S: v=WxPv/siO5l+qxN4

Why do the client and server echo each others' nonces?
Something about inserting random data into each other's messages?  If
so the client echo is not necessary, since it's included in the hash.
Or is it part of authenticating to each other?  The 'r:' description
in 4.1 says the client must verify the nonce, but the server need not.

>     First, the client sends a message containing the username, a list of
>     the hash functions it supports, and a random, unique nonce. In
>     response, the server sends its list of supported hash functions, an
>     iteration count i, the user's salt, and appends its own nonce to the
>     client-specified one.  The client then responds with the same nonce
>     and a ClientProof computed as explained earlier.

This looks both too inflexible and too flexible...

I imagine the desired iteration count could depend on the hash function:
The stronger/more expensive hash function, the weaker iteration count.
Or have I guessed wrong what this count is for?  (Please explain in
section 5.  How to pick a good iteration count?)

The admin could also increase the count for new hashes at some point,
but keep the old hashes with old iteration counts around for a while.

The client must also send the hash function again, if the server
announced several hashes.

However:

> 7. Security Considerations
>     If the server detects (from the value of the client-specified "h"
>     attribute) that both endpoints support a stronger hash function that
>     the one the client actually chooses to use, then it SHOULD treat
>     this as a downgrade attack and reject the authentication attempt.

This requires an ordering by strength which the peers agree on, so the
client can select a hash function the server will accept.  Instead, let
the server send a list of the hash functions it will accept in this auth
exchange.  (Intersection of the ones the client sent and the hashes
available for that user.)

But this "downgrade attack" can be performed easily enough by asking for
weak hash functions which the client is prepared to crack.  Maybe first
ask for only weak hash functions, then stronger in another auth
exchange.

If the server has a lockout after N failed auth attemts for a user, one
could explore the server a bit first by seeing what functions the server
offers for other users than the "target" user.

Back to section 4...
> 4.1 SCRAM attributes
>     - n:  (...)
>       The characters ',' or '=' in usernames are sent as '=2C' and '=3D'
>       respectively. If the server receives a username which contains '='
>       not followed by either '2C' or '3D', then the server MUST fail the
>       authentication.

Is that "MUST" important?  It means a protocol which uses UTF-8
identities but allows a wider character range than 'value-safe-char'
must use another escape mechanism in addition.

>     - r: (...) No quoting is applied to this string (unless
>       the binding of SCRAM to a particular protocol states otherwise).

What does this mean?  There isn't any quoting elsewhere in SCRAM either.
And it's not about '=' escaping, since the example shows 'r=' need
not be the last field.

>     - c: This optional attribute specifies base64-encoded channel-
>       binding data. It may be sent by either the client or the server.

In the first message which either sends?

>     - i: This attribute specifies an iteration count for the selected
>       hash function, and must be sent by the server along with the
>       user's salt.

A hostile server can perform a denial of service attack (against clients
for which this is a meaningful term) by sending a huge iteration count.
Clients can do the same if the server lets clients send plaintext
passwords which it will hash and store as their password, and it lets
clients configure their own hash function and iteration count.
Peers could check the count against a configured max value.  Servers
which allow clients to store a prehashed server secret with iteration
count, might also require the stored count to be reasonable.

> 7. Security Considerations
>     If the external security layer used to protect the SCRAM exchange
>     uses an anonymous key exchange,

What does that mean?  The server does not send a certificate or similar
ID?  Does it make a difference if the client is anonymous?

>     If an attacker obtains the authentication information from the
>     authentication repository and either eavesdrops on one
>     authentication exchange or impersonates a server, the attacker gains
>     the ability to impersonate that user to all servers providing SCRAM
>     access using the same password and salt.

same server secret (same hash function, iteration count, password, salt).

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2D7ZuU3092608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 00:35:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2D7Ztrm092607; Thu, 13 Mar 2008 00:35:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2D7ZomF092598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 13 Mar 2008 00:35:54 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JZhya-0007Z3-Fq for [e-mail]; Thu, 13 Mar 2008 07:35:44 +0000
Received: from hmbg-d9b88e38.pool.mediaways.net ([217.184.142.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 13 Mar 2008 07:35:44 +0000
Received: from nobody by hmbg-d9b88e38.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 13 Mar 2008 07:35:44 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Digest-MD5 to Historic
Date:  Thu, 13 Mar 2008 08:38:19 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 34
Message-ID: <fralg7$770$[e-mail]>
References:  <[e-mail]>            <[e-mail]> <fop89f$6m2$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e38.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> I think the text you've suggested would be good for an=20
> interoperability report on an update to DIGEST-MD5 itself.

I have just learned that XMPP also uses DIGEST-MD5, and my
MD5 test suite does not yet include the 3920bis example :-(

The complete "deprecate 2831" plan is premature, maybe we
should pick your old 2831bis draft, remove the new features
including "bindings", remove the old "auth" variants as not
unnecessary for current common practice, and publish the
rest as 2831bis "draft standard" with three clear warnings:

- interoperability is non-trivial, and guaranteed to fail
  for MD5-sess wrt RFC 2617 MD5-sess
- all passwords, user names, and realms are supposed to be
  in SASLprep UTF-8
- new intended usage "rare" or whatever the opposite of=20
  "common" is (=3D> update SASL registry), anybody trying to
  replace CRAMMD5 by DIGEST-MD5 is a public danger and in
  need of medical help ;-)

> My "DIGEST-MD5 to historic" draft was never intended as a
> detailed description of all things broken in DIGEST-MD5.

Yes, your 2831bis draft was better for this purpose.  When
you (this WG) decided to deprecate it, did anybody check=20
the normative references *to* RFC 2831 ?  Bill created a
nice tool for this job:
=20
http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=3Drfc2831

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CHrHdA095403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 10:53:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CHrH7w095402; Wed, 12 Mar 2008 10:53:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m2CHrFXu095393 for <[e-mail]>; Wed, 12 Mar 2008 10:53:16 -0700 (MST) (envelope-from [e-mail])
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06989; 12 Mar 2008 13:53 EDT
Date: Wed, 12 Mar 2008 13:53:03 -0400 (EDT)
From: Jeffrey Hutzelman <[e-mail]>
X-X-Sender:  <[e-mail]>
To: Chris Newman <[e-mail]>
cc: Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>, <[e-mail]>
Subject: Re: which is our DIGEST-MD5 successor?
In-Reply-To: <44ADB860B3FF5E9FF13784B6@446E7922C82D299DB29D899F>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 12 Mar 2008, Chris Newman wrote:

> If we have two wire encodings of the same mechanism, then SASL applications
> could access the same mechanism via two different names (e.g.,
> SASL-FRIENDLY-NAME, GS2-KSDJFHSLKDSF).  But a simple applicability
> statement to not use the latter in SASL-based protocols is sufficient to
> resolve interoperability problems for this case.  I can't see this as a
> matter that will cause significant confusion.

The problem in this case is that it requires GS2 implementations which
enumerate all GSS-API mechanisms and offer them all as SASL mechanisms to
know that _this_ mechanism is special and shouldn't be offered.  A large
part of the value of a wrapper is that it scales, making it unnecessary to
make specification or implementation changes to the SASL framework or SASL
applications for each new GSS-API mechanism.  Define a new mech (which
_anyone_ can do) and it just works.  The first time you require the
wrapper to handle a particular mechanism specially, you destroy that
property.




> While I prefer to avoid two different wire encodings for the same
function,
> I consider the deployability of the mechanism to be a much more important
> concern and the deployment impact of binary in the SASL authentication
> protocol is significant in my experience.

Let us please be clear.  SASL is not a text-based.  SASL is binary.
SASL-using application protocols may be text-based, and this often
requires them to hex- or base64-encode SASL messages.  You are not going
to be able to look at the bits on the wire and debug a SASL mechanism,
especially in the text-based protocols that are its major users, without
some decoding assistance.

For example, IMAP's AUTHENTICATE command exchanges base64-encoded tokens;
this means that you cannot read SCRAM's semi-human-readable tokens in a
packet trace.

SMTP's AUTH command behaves the same way.



I'm seeing an awful lot of "GS2 is going to make the wire encoding more
complicated!  It's binary; binary is always complicated!" and similar FUD.
I really wish people would stop spreading that, RIGHT NOW, and go actually
read (or re-read) the documents in question.

As has been said repeatedly and at multiple meetings, the only additional
constraints the GSS-API places on tokens exchanged by a mechanism is the
presence of standard framing on the first context token, which is used
primarily to allow the recipient of such a token to tell what mechanism it
belongs to.  SASL doesn't need this, but it needs to be present anyway in
order to allow a pure-sasl implementation to interoperate with a
deployment in which a GS2 implementation has been layered on top of the
SCRAM GSS-API mechanism, _which may be done by an adminstrator without
either component knowing about it in advance_.

The emphasized part is an important capability; it's akin to being able to
buy your IP service from someone other than who provides the DSL layer,
and that from someone other than the local phone company.  Or, if you
prefer, being able to buy your email service from someone other than your
ISP.


The same issue is likely to contain some other constraints, because GS2
must use the GSS-API's abstract interface and operate the same for every
mechanism.  So, for example, it's going to exchange some number of tokens
to establish a context, and then it's going to exchange a token to
authenticate the channel bindings.  That last token can often be sent in
the same message as the last token of the context exchange, saving a round
trip.  But this can be done only by putting them in the same SASL token,
which means we have to have some way of representing the length of the
first token and whether the second is present or will require a separate
message (possibly this could be inferred).  Sam and Nico will tell us
exactly what this might look like for SCRAM, but it's likely to involve a
count of some sort.


I'm sorry if you don't like binary protocols, but I don't find "I prefer
ASCII only" a compelling argument for introducing market confusion,
interoperability problems, and/or implementation complexity in what is,
after all, _already_ a binary protocol.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CF4nAb076085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 08:04:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CF4nDh076084; Wed, 12 Mar 2008 08:04:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fugue.toroid.org (fugue.toroid.org [85.10.196.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CF4lES076073 for <[e-mail]>; Wed, 12 Mar 2008 08:04:48 -0700 (MST) (envelope-from [e-mail])
Received: from penne.toroid.org (localhost [127.0.0.1]) by fugue.toroid.org (Postfix) with ESMTP id 8B3CE558253; Wed, 12 Mar 2008 16:04:44 +0100 (CET)
Received: by penne.toroid.org (Postfix, from userid 1000) id 7AAA1ADC171; Wed, 12 Mar 2008 20:34:38 +0530 (IST)
Date: Wed, 12 Mar 2008 20:34:38 +0530
From: Abhijit Menon-Sen <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Message-ID: <[e-mail]>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]> <D0E775FEB1A541ADBC822D68@446E7922C82D299DB29D899F>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D0E775FEB1A541ADBC822D68@446E7922C82D299DB29D899F>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2008-03-12 09:33:43 -0500, [e-mail] wrote:
>
> > Regarding the SCRAM draft, I hope there'll be a version soon which
> > spells out what each challenge and response consists of, and what
> > the server must remember (or be able to construct).  It's cumbersome
> > to dig around in the parameter descriptions in order to figure that
> > out.
> 
> Agree this needs work.  I simply don't have time to be the active
> editor on the document.

I do, but I've held off working on the examples and appendices until I
have a better understanding of what to do about GS2/GSSAPI. Neither is
of any interest to me personally, but if anyone can suggest changes to
accommodate GS* without making the SASL mechanism harder to understand
or significantly harder to implement and test, I'll incorporate those
changes in the interests of achieving wider acceptance.

I haven't received any suggestions I can act upon yet, but Simon seems
to be working on merging his draft with SCRAM. I'll wait and see how
that works out.

-- ams



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CEB3dX067158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 07:11:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CEB3e5067157; Wed, 12 Mar 2008 07:11:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CEB0ah067125 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 12 Mar 2008 07:11:01 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CEB00Z014445 for <[e-mail]>; Wed, 12 Mar 2008 07:11:00 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 12 Mar 2008 07:11:00 -0700 (PDT)
Received: from [10.0.1.4] (dhcp-1288.ietf71.ietf.org [130.129.18.136]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Wed, 12 Mar 2008 07:10:56 -0700 (PDT)
Date: Wed, 12 Mar 2008 10:11:19 -0500
From: Chris Newman <[e-mail]>
Subject: Re: which is our DIGEST-MD5 successor?
In-reply-to: <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>
Cc: [e-mail]
Message-id: <44ADB860B3FF5E9FF13784B6@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On March 11, 2008 7:16:50 -0400 Jeffrey Hutzelman <[e-mail]> wrote:
> I would be very disappointed to see separate password mechanisms for SASL
> and GSS-API, rather than one mechanism that can be used with either.
> Producing only a SASL mechanism would fail to meet the needs of GSS-API
> applications desiring support for password authentication

Having separate password-based mechanisms for SASL and GSS-API would be 
lunacy, IMHO.  Having the same password-based mechanism with different 
on-wire encodings for SASL and GSS-API is an option I want to leave on the 
table until I've seen the impact of GS2 on the on-wire encoding.

If the impact of GS2 on the authentication protocol is a fixed-size binary 
blob at the beginning of the protocol exchange (that can simply be omitted 
from diagnostic output and made optional when the code is running in debug 
mode), then I'm fine with a combined mechanism.  If the impact of GS2 is 
variable-sized binary or binary in multiple places in the authentication 
protocol, then I'd be much less comfortable with a dual-purpose 
wire-encoding.

If we have two wire encodings of the same mechanism, then SASL applications 
could access the same mechanism via two different names (e.g., 
SASL-FRIENDLY-NAME, GS2-KSDJFHSLKDSF).  But a simple applicability 
statement to not use the latter in SASL-based protocols is sufficient to 
resolve interoperability problems for this case.  I can't see this as a 
matter that will cause significant confusion.

While I prefer to avoid two different wire encodings for the same function, 
I consider the deployability of the mechanism to be a much more important 
concern and the deployment impact of binary in the SASL authentication 
protocol is significant in my experience.

While I once thought use of NUL for field delimiters in SASL PLAIN was 
clever (as it may benefit languages with NUL terminated strings and avoids 
quoting), my subsequent experience indicates it was a design error (not 
significant enough to merit a change now, but a mistake to avoid in the 
future).

		- Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CDtWCm064558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 06:55:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CDtWed064557; Wed, 12 Mar 2008 06:55:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CDtTZt064550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 12 Mar 2008 06:55:31 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2CDtEPe009084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 14:55:14 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Steven Simon <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]> <71988C2E7B982A1C1B9243A6@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080312:[e-mail]::Rosir2qujURgxFvh:3QsJ
X-Hashcash: 1:22:080312:[e-mail]::q2yrMnOtWLseUheE:6Jgo
X-Hashcash: 1:22:080312:[e-mail]::55k6WbUQrzTXqazF:S8g0
X-Hashcash: 1:22:080312:[e-mail]::Pe3ABbnJYfWTkQ1d:mZZV
Date: Wed, 12 Mar 2008 14:55:14 +0100
In-Reply-To: <71988C2E7B982A1C1B9243A6@446E7922C82D299DB29D899F> (Chris Newman's message of "Wed, 12 Mar 2008 09:15:51 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

>> Desirable on-disk hash features:
>> * salted
>> * iteration count
>
> Obviously, I agree these are desirable as they're in SCRAM ;-).  I
> consider the iteration count necessary if the mechanism is to have any
> utility without TLS.

It may be useful to understand early on whether SCRAM without a
successful channel binding is going to be acceptable to the IETF
community and perhaps in particular to the IESG.

The obvious problem is that authentication without session data
integrity protection is vulnerable to active attackers hi-jacking the
session after successful authentication.

I think it would be acceptable to have an option whereby if peers
actively accepts the threat, the protocol works even if there is no
session data protection.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CDXLhF061698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 06:33:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CDXLYv061696; Wed, 12 Mar 2008 06:33:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CDXKtA061686 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 12 Mar 2008 06:33:21 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CDXKZl012343 for <[e-mail]>; Wed, 12 Mar 2008 06:33:20 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 12 Mar 2008 06:33:20 -0700 (PDT)
Received: from [10.0.1.4] (dhcp-1288.ietf71.ietf.org [130.129.18.136]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Wed, 12 Mar 2008 06:33:20 -0700 (PDT)
Date: Wed, 12 Mar 2008 09:33:43 -0500
From: Chris Newman <[e-mail]>
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
In-reply-to: <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Message-id: <D0E775FEB1A541ADBC822D68@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On March 11, 2008 14:08:06 +0100 Hallvard B Furuseth 
<[e-mail]> wrote:
> I don't get this.  SASL is not a protocol.  If a textual protocol _uses_
> SASL, it must turn SASL blobs into text - e.g. by base64-encoding them.
> If the SASL mechanism also base64-encodes, we get base64(base64(data)).

SASL is an abstraction model that combines two protocols: an authentication 
mechanism protocol and an application protocol with SASL profile.

The experience I've had with binary authentication mechanism protocols is 
less than stellar.  My product included a non-standard "proxyauth 
<username>" command that could be issued after authentication for 
administrative impersonation of a specific user.  We also have support for 
SASL PLAIN with authorization identity which is the standard way to provide 
the same functionality.  But trying to convince people to use the standard 
protocol rather than the non-standard one has been extremely difficult due 
to the binary nature of SASL PLAIN.  The problem is people don't like to 
use SASL PLAIN because the NUL octets make it difficult to generate and 
debug the authentication protocol and custom tools are required to do so. 
And PLAIN is a really simple case.

Binary creates a barrier to deployment and comprehension of the 
authentication protocol in my experience.

> Another feature: Don't disclose the existence/absense of a user unless
> authentication succeeds.  Or at least don't require it to be disclosed.
> See my messages "Hide presence/absence of users in server (HEXA, SCRAM)"
> of 30 Apr 2007.

IMHO, this is a tradeoff between security and usability that has to be 
configurable.  I agree all products should have a way to obscure the 
distinction between user-doesn't-exist and authentication failed, but for 
many deployments the usability benefit of exposing users under some 
circumstances greatly exceeds the security benefit of hiding this 
information.

> Regarding the SCRAM draft, I hope there'll be a version soon which
> spells out what each challenge and response consists of, and what the
> server must remember (or be able to construct).  It's cumbersome to
> dig around in the parameter descriptions in order to figure that out.

Agree this needs work.  I simply don't have time to be the active editor on 
the document.

		- Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CDFWg5059436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 06:15:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CDFWwi059435; Wed, 12 Mar 2008 06:15:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CDFTaE059408 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 12 Mar 2008 06:15:32 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2CDFTQn011536 for <[e-mail]>; Wed, 12 Mar 2008 06:15:29 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 12 Mar 2008 06:15:29 -0700 (PDT)
Received: from [10.0.1.4] (dhcp-1288.ietf71.ietf.org [130.129.18.136]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Wed, 12 Mar 2008 06:15:29 -0700 (PDT)
Date: Wed, 12 Mar 2008 09:15:51 -0500
From: Chris Newman <[e-mail]>
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
In-reply-to: <[e-mail]>
To: Steven Simon <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Message-id: <71988C2E7B982A1C1B9243A6@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=utf-8
Content-transfer-encoding: QUOTED-PRINTABLE
Content-disposition: inline
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On March 11, 2008 5:14:14 -0700 Steven Simon <[e-mail]> wr=
ote:
> I would like a client-first mechanism that sends the username befor=
e 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 loca=
tion.

I'd put this in the nice-to-have category.  The earlier the username =
is=20
sent, the more proxy-friendly the mechanism becomes, but there are wa=
ys to=20
deal with this otherwise.

> Desirable on-disk hash features:
> * salted
> * iteration count

Obviously, I agree these are desirable as they're in SCRAM ;-).  I co=
nsider=20
the iteration count necessary if the mechanism is to have any utility=
=20
without TLS.

> =E2=80=A2 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 reconf=
igure=20
the
> clients.

Hash agility is needed, but sub-negotiation can create more problems =
than=20
it solves.  To keep the mechanism and negotiation simpler, I'd prefer=
 the=20
hash be part of the mechanism name and we simply have a different mec=
hanism=20
for each hash.  The agility plan needs to be written, but I prefer an=
=20
approach where clients "latch-up" to better mechanisms, handle a=20
transition-needed error code gracefully and servers aggressively popu=
late=20
all supported password verifiers whenever possible (e.g. password cha=
nge=20
and/or successful use of TLS+plain).

> BTW: we do use the privacy layer, though I think we can work around=
 its
> exclusion.

Interesting.  Do you also support TLS?  Would your code be simpler wi=
th TLS=20
and channel bindings but no SASL privacy layer?

=09=09- Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CD0dR1057623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 06:00:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CD0dJ5057622; Wed, 12 Mar 2008 06:00:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CD0b4i057614 for <[e-mail]>; Wed, 12 Mar 2008 06:00:38 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.21.224] (dhcp-15e0.ietf71.ietf.org [130.129.21.224])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 12 Mar 2008 13:00:36 +0000
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2008 12:09:23 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Frank Ellermann <[e-mail]>
CC: [e-mail]
Subject: Re: Digest-MD5 to Historic
References: <[e-mail]> <[e-mail]> <fop89f$6m2$[e-mail]>
In-Reply-To: <fop89f$6m2$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Frank Ellermann wrote:

>Hi, 
>
>here is the proposed text explaining the MD5-SESS Digest-MD5
>problem.  I could transform it into xml2rfc format if needed.
>  
>
Hi Frank,
I think the text you've suggested would be good for an interoperability 
report on an update to DIGEST-MD5 itself.
My "DIGEST-MD5 to historic" draft was never intended as a detailed 
description of all things broken in DIGEST-MD5.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CCs8uN056594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 05:54:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CCs8tl056593; Wed, 12 Mar 2008 05:54:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CCs4Jw056582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 12 Mar 2008 05:54:06 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2CCrwMp032278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 13:54:00 +0100
From: Simon Josefsson <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Chris Newman <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080312:[e-mail]::qxGo5VZDem9IlUYe:4ImS
X-Hashcash: 1:22:080312:[e-mail]::wnijrDLHxQ2ZkcVh:9028
X-Hashcash: 1:22:080312:[e-mail]::07BGUYL4tkGbJMJj:BvqP
X-Hashcash: 1:22:080312:[e-mail]::Val8es8k1rdd3AmQ:Ydif
Date: Wed, 12 Mar 2008 13:53:58 +0100
In-Reply-To: <[e-mail]> (Hallvard B. Furuseth's message of "Wed, 12 Mar 2008 10:12:57 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth <[e-mail]> writes:

> Simon Josefsson writes:
>>Hallvard B Furuseth <[e-mail]> writes:
>>> I don't get this.  SASL is not a protocol.  If a textual protocol _uses_
>>> SASL, it must turn SASL blobs into text - e.g. by base64-encoding them.
>> (...)
>> Hex encoding the data as well doesn't cost much, and allows for simpler
>> string handling in some programming languages.
>
> Programs that treat SASL blobs as text are broken and possibly a
> security hazard.  At least unless they check the syntax first.
> (For C, that the blob contains no '\0'.)

Sure, but internally in a mechanism, using text can simplify parsing and
debugging for some programming languages.

(But it can also complicate parsing... see DIGEST-MD5)

I don't feel strongly about it, but it may be a good idea.  There is
precedent given PLAIN, CRAM-MD5 and DIGEST-MD5.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2C9DGDB026094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 02:13:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2C9DGh5026093; Wed, 12 Mar 2008 02:13:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2C9D966026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 12 Mar 2008 02:13:11 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZN18-0003hM-64; Wed, 12 Mar 2008 10:12:58 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx8.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZN17-0001Kq-S7; Wed, 12 Mar 2008 10:12:58 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JZN17-0004Rv-DI; Wed, 12 Mar 2008 10:12:57 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2008 10:12:57 +0100
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
In-Reply-To: <[e-mail]>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: D1A2F681ADB59190E596E60DAF0542DF3472A016
X-UiO-SR-test: A8A75255FCFD9ED2E217F71090864723C5834494
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 535 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
>Hallvard B Furuseth <[e-mail]> writes:
>> I don't get this.  SASL is not a protocol.  If a textual protocol _uses_
>> SASL, it must turn SASL blobs into text - e.g. by base64-encoding them.
> (...)
> Hex encoding the data as well doesn't cost much, and allows for simpler
> string handling in some programming languages.

Programs that treat SASL blobs as text are broken and possibly a
security hazard.  At least unless they check the syntax first.
(For C, that the blob contains no '\0'.)

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2C7Obma013734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 00:24:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2C7ObGT013733; Wed, 12 Mar 2008 00:24:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2C7OaJL013726 for <[e-mail]>; Wed, 12 Mar 2008 00:24:37 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id AF7764AC8E; Wed, 12 Mar 2008 08:24:35 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1205306675-87171-26; Wed, 12 Mar 2008 08:24:35 +0100
Message-Id: <[e-mail]>
Date: Wed, 12 Mar 2008 08:24:35 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Cc: Kurt Zeilenga <[e-mail]>, Chris Newman <[e-mail]>, Hallvard B Furuseth <[e-mail]>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]> <B6zDajb/[e-mail]>
In-Reply-To: <B6zDajb/[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Oops, I wasn't really awake. That disclosure happens outside SASL, and 
any SASL requirement does not apply. Sorry.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2C7DvBH012057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 00:13:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2C7DveD012056; Wed, 12 Mar 2008 00:13:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2C7DqMs012041 for <[e-mail]>; Wed, 12 Mar 2008 00:13:55 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 19F054AC8B; Wed, 12 Mar 2008 08:13:49 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1205306028-87171-17; Wed, 12 Mar 2008 08:13:48 +0100
Message-Id: <B6zDajb/[e-mail]>
Date: Wed, 12 Mar 2008 08:13:48 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Cc: Kurt Zeilenga <[e-mail]>, Chris Newman <[e-mail]>, Hallvard B Furuseth <[e-mail]>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth writes:
> Another feature: Don't disclose the existence/absense of a user unless 
> authentication succeeds.

Strong disagreement.

> Or at least don't require it to be disclosed.

Perfectly okay.

An example of the difference: Suppose the mechanism uses a password and 
the user's password (matches but) is expired. In that case it's 
reasonable to fail authentication, but an implementation may also wish 
to reveal that the user exists by saying "go get a new password, the 
one you're using has expired".

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BLY8P7054981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 14:34:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BLY8SR054980; Tue, 11 Mar 2008 14:34:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BLY5Pd054972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 14:34:07 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JZC6j-0007wR-33 for [e-mail]; Tue, 11 Mar 2008 21:34:01 +0000
Received: from hmbg-d9b88e36.pool.mediaways.net ([217.184.142.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 21:34:01 +0000
Received: from nobody by hmbg-d9b88e36.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 21:34:01 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: which is our DIGEST-MD5 successor?
Date:  Tue, 11 Mar 2008 22:36:21 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 16
Message-ID: <fr6ts0$rb5$[e-mail]>
References:  <[e-mail]><[e-mail]> <fr51no$jdj$[e-mail]><[e-mail]> <fr638g$vgu$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e36.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu wrote:
=20
> that references an IPR notice claiming that the NSA makes
> the patent available royalty-free.

If you are talking about the IPR statement submitted by
Simon based on a report from a conference discussing hash
functions, that is what I had in mind:
<https://datatracker.ietf.org/ipr/795/>
<http://www.google.com/patents?q=3D6829355>

I only looked once in the NIST PDF referenced by RFC 4634.
Just copying the example code "as is" might be not good
enough for some applications:  IANAL.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BL44f5052550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 14:04:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BL448P052549; Tue, 11 Mar 2008 14:04:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BL411O052543 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 14:04:03 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JZBdg-0006Jt-KJ for [e-mail]; Tue, 11 Mar 2008 21:04:00 +0000
Received: from hmbg-d9b88e36.pool.mediaways.net ([217.184.142.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 21:04:00 +0000
Received: from nobody by hmbg-d9b88e36.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 21:04:00 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Date:  Tue, 11 Mar 2008 22:06:20 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 14
Message-ID: <fr6s3o$kns$[e-mail]>
References:  <[e-mail]><273158112E585E37B50033A2@446E7922C82D299DB29D899F><[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e36.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

> I would recommend against using base64 in the mechanism for this
> reason.  Base64 is considerably more error prone to implement
> than hex encoding.

> This wastes a few bytes, yes, but I don't think the difference
> is significant.

+1  I was not amused when I found that an early SCRAM B64 example
triggered a "cannot happen" state in my B64 decoder.  Of course
that was my fault, but it is definitely harder to get hex. wrong.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGpgW7028090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 09:51:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BGpg1o028089; Tue, 11 Mar 2008 09:51:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGpe7g028080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 11 Mar 2008 09:51:41 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2BGpXJd020159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 17:51:33 +0100
From: Simon Josefsson <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Chris Newman <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080311:[e-mail]::2dWllVr7xZVVGAdR:6r/U
X-Hashcash: 1:22:080311:[e-mail]::DvJA55pTXRxI9mxS:Evdf
X-Hashcash: 1:22:080311:[e-mail]::fMDHiAq7uhnPh5yt:HBF7
X-Hashcash: 1:22:080311:[e-mail]::wPG3MaZax6E6QkKd:c0pY
Date: Tue, 11 Mar 2008 17:51:33 +0100
In-Reply-To: <[e-mail]> (Hallvard B. Furuseth's message of "Tue, 11 Mar 2008 17:08:06 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth <[e-mail]> writes:

> Chris Newman writes:
>> Nice-to-have features:
>> (...)
>> * Textual protocol like CRAM-MD5 over binary protocol that's harder
>>   to test/debug
>
> I don't get this.  SASL is not a protocol.  If a textual protocol _uses_
> SASL, it must turn SASL blobs into text - e.g. by base64-encoding them.
> If the SASL mechanism also base64-encodes, we get base64(base64(data)).

CRAM-MD5 uses hex encoding, so it will be base64(hex(data)).  I would
recommend against using base64 in the mechanism for this reason.  Base64
is considerably more error prone to implement than hex encoding.

This wastes a few bytes, yes, but I don't think the difference is
significant.

> If you are thinking of text vs ASN.1 I agree ASN.1 is harder to examine,
> but there are plenty of middle ways.  E.g. a fixed-field format with a
> field separator need not be textual.  And such binary fields could still
> start with 'token=' to identify them when you read the protocol.

Hex encoding the data as well doesn't cost much, and allows for simpler
string handling in some programming languages.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGmoPf027793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 09:48:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BGmo04027792; Tue, 11 Mar 2008 09:48:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGmmaD027781 for <[e-mail]>; Tue, 11 Mar 2008 09:48:48 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2BGmlWc022034 for <[e-mail]>; Tue, 11 Mar 2008 16:48:48 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2BGmlYH053688 for <[e-mail]>; Tue, 11 Mar 2008 10:48:47 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2BGml0G009808; Tue, 11 Mar 2008 11:48:47 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2BGmk6N009807; Tue, 11 Mar 2008 11:48:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 11 Mar 2008 11:48:46 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Holding gs2
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 11, 2008 at 12:24:43PM -0400, Sam Hartman wrote:
> Sam is horribly confused here.  [...]


Well, so am I.  Can we discuss this sometime this week?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGfXSY027035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 09:41:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BGfXZL027034; Tue, 11 Mar 2008 09:41:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGfVOg027028 for <[e-mail]>; Tue, 11 Mar 2008 09:41:32 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.21.224] (dhcp-15e0.ietf71.ietf.org [130.129.21.224])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 11 Mar 2008 16:41:30 +0000
Message-ID: <[e-mail]>
Date: Tue, 11 Mar 2008 16:41:24 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>
CC: [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Very useful summary.
>
+1.

>I agree with all those requirements, except that I have some reservation
>about using a textual protocol.  My experience with DIGEST-MD5 has been
>that the free format created more problems than it solved.  There are
>still interop problems with quoted text.  I recall interop problems
>caused by the specification permitting empty comma sequences like ", ,".  
>
Indeed.

>If it is a textual protocol, I would want it to only permit ONE way to
>say the same thing.
>
>Reordering parameters so that 'foo=bar,baz=apa' is
>equivalent to 'baz=apa,foo=bar' is bad.  Permitting whitespace so that
>'foo=bar, baz=apa' is also equivalent is bad.  Using quoting, so that
>'foo="bar",baz=apa' is also equivalent is bad.  Allowing unrecognized
>parameters to be skipped is bad.  And so on.  
>
Agreed.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGOjIB025739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 09:24:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BGOj8q025738; Tue, 11 Mar 2008 09:24:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (dhcp-178f.ietf71.ietf.org [130.129.23.143]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BGOi5s025731 for <[e-mail]>; Tue, 11 Mar 2008 09:24:45 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E079E476D; Tue, 11 Mar 2008 12:24:43 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Holding gs2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 11 Mar 2008 12:24:43 -0400
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 29 Jan 2008 15:26:05 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Nicolas" == Nicolas Williams <[e-mail]> writes:

    Nicolas> On Tue, Jan 29, 2008 at 12:16:36PM -0700, Chris Newman
    Nicolas> wrote:
    >> Speaking as a technical participant only...
    >> 
    >> As a SASL implementer, it is my current intention to not
    >> implement the "security layer" feature of SASL.  If I implement
    >> GS2, my implementation will always negotiate the GS2 security
    >> layer off and will use SSL/TLS channel bindings if there's any
    >> reasonable way I can get that working with the Mozilla/NSS
    >> library.

    Nicolas> Most SASL apps have StartTLS or TLS port options.  I'm
    Nicolas> inclined to believe that most SASL implementors would
    Nicolas> prefer to just do channel binding to TLS when you want
    Nicolas> security layers.

    Nicolas> So I'm now inclined to believe that Sam is right: we may
    Nicolas> have gone overboard with GS2.

Sam is horribly confused here.  In particular Nico seems to believe
I'm worried that you have to implement MIC tokens in pure SASL
mechanisms.  I don't think I've expressed that worry.

I think Nico is reading objections I've never made into my statements.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BG8DgR024343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 09:08:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BG8Dmr024342; Tue, 11 Mar 2008 09:08:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BG8Arq024332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 09:08:12 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZ71L-0006hV-JM; Tue, 11 Mar 2008 17:08:07 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JZ71L-0001q2-A0; Tue, 11 Mar 2008 17:08:07 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1JZ71K-0003Hc-V4; Tue, 11 Mar 2008 17:08:06 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Tue, 11 Mar 2008 17:08:06 +0100
To: Chris Newman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
In-Reply-To: <273158112E585E37B50033A2@446E7922C82D299DB29D899F>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: A3479ACA98F9753F510F53D18A4105112893C632
X-UiO-SR-test: AA4ECC76987E844200194E162404E4E10E140BFA
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 533 max/h 5 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman writes:
> Nice-to-have features:
> (...)
> * Textual protocol like CRAM-MD5 over binary protocol that's harder
>   to test/debug

I don't get this.  SASL is not a protocol.  If a textual protocol _uses_
SASL, it must turn SASL blobs into text - e.g. by base64-encoding them.
If the SASL mechanism also base64-encodes, we get base64(base64(data)).

If you are thinking of text vs ASN.1 I agree ASN.1 is harder to examine,
but there are plenty of middle ways.  E.g. a fixed-field format with a
field separator need not be textual.  And such binary fields could still
start with 'token=' to identify them when you read the protocol.


Another feature: Don't disclose the existence/absense of a user unless
authentication succeeds.  Or at least don't require it to be disclosed.
See my messages "Hide presence/absence of users in server (HEXA, SCRAM)"
of 30 Apr 2007.


Regarding the SCRAM draft, I hope there'll be a version soon which
spells out what each challenge and response consists of, and what the
server must remember (or be able to construct).  It's cumbersome to
dig around in the parameter descriptions in order to figure that out.

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFk82T022009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 08:46:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BFk8oH022008; Tue, 11 Mar 2008 08:46:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fugue.toroid.org (fugue.toroid.org [85.10.196.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFk3Ce021979 for <[e-mail]>; Tue, 11 Mar 2008 08:46:05 -0700 (MST) (envelope-from [e-mail])
Received: from penne.toroid.org (localhost [127.0.0.1]) by fugue.toroid.org (Postfix) with ESMTP id 693D15582B9; Tue, 11 Mar 2008 16:45:59 +0100 (CET)
Received: by penne.toroid.org (Postfix, from userid 1000) id 5321DADC171; Tue, 11 Mar 2008 21:15:54 +0530 (IST)
Date: Tue, 11 Mar 2008 21:15:54 +0530
From: Abhijit Menon-Sen <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Message-ID: <[e-mail]>
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2008-03-11 16:11:09 +0100, [e-mail] wrote:
>
> Very useful summary.
> 
> I agree with all those requirements, except [...]

Yes, I like the list too. Thanks, Chris.

> If it is a textual protocol, I would want it to only permit ONE way to
> say the same thing.

I would strongly prefer a textual protocol, and I agree that it should
have a restrictive syntax. (I am anxious to not repeat my experiences
implementing and writing tests for DIGEST-MD5 ;). I think this is what
the "Silly syntax variations" item in Chris's list is addressing too.

> Finally, there is no conflict between avoiding ASN.1 and using
> GSS-API.

(I'm very glad to hear that.)

-- ams



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFEL8h019006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 08:14:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BFEL7u019005; Tue, 11 Mar 2008 08:14:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFEJba018999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 08:14:20 -0700 (MST) (envelope-from [e-mail])
Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 74DA4251A842 for <[e-mail]>; Tue, 11 Mar 2008 08:14:19 -0700 (PDT)
Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 614BE464007 for <[e-mail]>; Tue, 11 Mar 2008 08:14:19 -0700 (PDT)
X-AuditID: 11807135-a5c23bb0000073f7-36-47d6a1cb7b84
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay12.apple.com (Apple SCV relay) with ESMTP id 3FA9C420008 for <[e-mail]>; Tue, 11 Mar 2008 08:14:19 -0700 (PDT)
Received: from [192.168.1.201] (adsl-75-18-160-61.dsl.pltn13.sbcglobal.net [75.18.160.61]) by et.apple.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]> for [e-mail]; Tue, 11 Mar 2008 08:14:19 -0700 (PDT)
Date: Tue, 11 Mar 2008 08:14:14 -0700
From: Steven Simon <[e-mail]>
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
In-reply-to: <273158112E585E37B50033A2@446E7922C82D299DB29D899F>
To: Chris Newman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.919.2)
Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-transfer-encoding: quoted-printable
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F>
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello

There are a couple of qualities that are important to me. I believe =20
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 =20
the challenge.
My system supports multiple directories so I need to be able to route =20=

the session
to the correct one based on the user account location.

I would also like the hash stored on disk to have arbitrary =20
complexity. I've done
some brute-force cracking tests. I find that a 4-core Mac Pro can =20
typically break
7-character passwords with a simple (salt+hash) in under a day. We =20
could also
use OpenCL to use the 120 cores on the GPU to up the speed. Because =20
we're
dealing with the "stolen laptop case" in addition to locked-room =20
servers, this
vulnerability is of special concern.

Desirable on-disk hash features:
* salted
* iteration count
=95 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 =20
right hash
before producing the response. We don't want to have to reconfigure =20
the clients.

BTW: we do use the privacy layer, though I think we can work around =20
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 =
<[e-mail]=20
> > wrote:
>> In response to reviewer comments on our charter proposal, we need to
>> quickly produce replacement text which clarifies the qualities we =20
>> desire
>> the DIGEST-MD5 replacement mechanism to have.
>>
>> I'd like one or two persons (working together) to take a quick stab =20=

>> at
>> this (for initial WG review BEFORE our IETF#71 session).  Any =20
>> 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 =20
> store) that is not
> the password itself
> * Ability to use one layer of reverse/server-side proxy where the =20
> proxy doesn't have a
> direct copy of the password verifier database and doesn't require =20
> administrative
> credentials to back-end
> * Has equivalent of both server & client nonces (to avoid CRAM-MD5 =20
> 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 =20=

> itself
> * Require a write operation to the server credential verifier =20
> database on every login
> * Include a rarely used optional feature, such as a SASL security =20
> layer.
> * Silly syntax variations that create interop problems (folding =20
> 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 =20=

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFDL8C018940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 08:13:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BFDLrh018939; Tue, 11 Mar 2008 08:13:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFDJJ0018932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 08:13:21 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BFDIoJ000779; Tue, 11 Mar 2008 11:13:18 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m2BFDHFK023782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 11:13:17 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m2BFDHAJ013496; Tue, 11 Mar 2008 11:13:17 -0400 (EDT)
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
References: <[e-mail]> <[e-mail]> <fr51no$jdj$[e-mail]> <[e-mail]> <fr638g$vgu$[e-mail]>
From: Tom Yu <[e-mail]>
Date: Tue, 11 Mar 2008 11:13:16 -0400
In-Reply-To: <fr638g$vgu$[e-mail]> (Frank Ellermann's message of "Tue, 11 Mar 2008 15:02:14 +0100")
Message-ID: <[e-mail]>
Lines: 14
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Frank Ellermann" <[e-mail]> writes:

> A somewhat longer version:  I don't trust SHA-*, I
> think that folks wanting SHA-* claiming that it is
> "better" often miss more than one point, I don't
> have the 30..100K USD for a certificate (see SAAG
> thread), and I don't like the SHA-* patent.  

Could you please elaborate on the SHA-* patent?  I only see one
message in the SAAG mailing list recently about that patent, and that
references an IPR notice claiming that the NSA makes the patent
available royalty-free.

---Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFBOnh018735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 08:11:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BFBOCt018734; Tue, 11 Mar 2008 08:11:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BFBKLI018724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 11 Mar 2008 08:11:22 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2BFB9kt001853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 16:11:11 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
References: <[e-mail]> <273158112E585E37B50033A2@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080311:[e-mail]::z1Sb6l9rdOmspPYj:0Po7
X-Hashcash: 1:22:080311:[e-mail]::/nhnwaOrQ6nxVgvI:4QpM
X-Hashcash: 1:22:080311:[e-mail]::8KAOH6xfH/vYmkTm:PEsi
Date: Tue, 11 Mar 2008 16:11:09 +0100
In-Reply-To: <273158112E585E37B50033A2@446E7922C82D299DB29D899F> (Chris Newman's message of "Tue, 11 Mar 2008 10:25:42 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> --On March 6, 2008 5:59:06 -0800 Kurt Zeilenga
> <[e-mail]> 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

Very useful summary.

I agree with all those requirements, except that I have some reservation
about using a textual protocol.  My experience with DIGEST-MD5 has been
that the free format created more problems than it solved.  There are
still interop problems with quoted text.  I recall interop problems
caused by the specification permitting empty comma sequences like ", ,".

If it is a textual protocol, I would want it to only permit ONE way to
say the same thing.  Reordering parameters so that 'foo=bar,baz=apa' is
equivalent to 'baz=apa,foo=bar' is bad.  Permitting whitespace so that
'foo=bar, baz=apa' is also equivalent is bad.  Using quoting, so that
'foo="bar",baz=apa' is also equivalent is bad.  Allowing unrecognized
parameters to be skipped is bad.  And so on.

If this approach is used, I would prefer a textual protocol too.

Finally, there is no conflict between avoiding ASN.1 and using GSS-API.
The ASN.1 used by GSS-API is minimal and does not need a DER parser or
encoder.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BEPM3T013631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 07:25:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BEPMMG013630; Tue, 11 Mar 2008 07:25:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BEPLtf013622 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 07:25:22 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2BEPKwp024111 for <[e-mail]>; Tue, 11 Mar 2008 07:25:21 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 11 Mar 2008 07:25:20 -0700 (PDT)
Received: from [10.0.1.4] ([130.129.81.26]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Tue, 11 Mar 2008 07:25:20 -0700 (PDT)
Date: Tue, 11 Mar 2008 10:25:42 -0500
From: Chris Newman <[e-mail]>
Subject: Re: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
In-reply-to: <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, [e-mail]
Message-id: <273158112E585E37B50033A2@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On March 6, 2008 5:59:06 -0800 Kurt Zeilenga <[e-mail]> 
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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BEH7ls012154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 07:17:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BEH7Xc012153; Tue, 11 Mar 2008 07:17:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BEH5hs012128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 11 Mar 2008 07:17:06 -0700 (MST) (envelope-from [e-mail])
Received: from 68-246-212-81.area3.spcsdns.net (68-246-212-81.area3.spcsdns.net [68.246.212.81]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2BEGutr006614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 10:16:58 -0400 (EDT)
Date: Tue, 11 Mar 2008 10:16:50 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, March 10, 2008 11:47:42 PM +0100 Simon Josefsson 
<[e-mail]> wrote:

>
> Tom Yu <[e-mail]> writes:
>
>> We have had several password-based SASL mechanism proposals submitted
>> to the WG for the purpose of replacing DIGEST-MD5.  Much of our
>> discussion has centered on SCRAM, but I would like to make sure that
>> we have consensus behind SCRAM and that all proposals presented to us
>> have been adequately considered.
>>
>> I believe the HEXA proposal has been merged into SCRAM.  Simon
>> Josefsson has also submitted a password-based mechanism.  During
>> IETF70, I had misunderstood Simon's intention with this document and
>> believed that he was withdrawing it.  Simon has since stated that he
>> intends to continue pursuing his document.  The document remains
>> expired, as far as I can tell, so this may not be relevant anymore.
>> (Simon, do you intend to renew the document?)
>
> Let me clarify: given that there weren't much interest from the SASL
> community, I didn't think there were any point in describing the SASL
> mappings of the GSS-API mechanism that my document specifies.  I may
> have said that I would retire that part of the document.  My intention
> is still to pursue the rest of the document as a normal GSS-API
> mechanism.  I always wanted it possible to use the mechanism with GS2,
> and when implementing I would probably use that as the first test case.
>
> I do intend to pursue the GSS-API mechanism part of that document, but
> alas haven't had time to implement it yet.  My document doesn't
> necessarily have to be an IETF document though.  If SCRAM evolves into a
> GSS-API mechanism, I would consider to use that instead, and drop my
> proposal.  Or we could merge SCRAM and my draft, if people can agree on
> the design.  My requirements are that it should be a GSS-API mechanism
> and that it should use hashing, and not be specific to the SASL context.
> I don't think I have other strong requirements.
>
> A SASL-specific password-mechanism is likely to be simpler than a
> GSS-API mechanism from a specification complexity point of view.  If
> people want a dead simple SASL password mechanism specification that do
> not mention GSS-API, I don't think that approach is compatible with my
> goals.  Then we'll end up with two solutions for these two different
> goals.

I would be very disappointed to see separate password mechanisms for SASL 
and GSS-API, rather than one mechanism that can be used with either. 
Producing only a SASL mechanism would fail to meet the needs of GSS-API 
applications desiring support for password authentication (I would expect 
those to include NFSv4, though I haven't actually talked to that community).


While meeting the needs of pure GSS-API applications is not part of the 
SASL WG's mandate, I think we need to consider that there is going to be 
some demand for such a mechanism, which means it's likely to get done -- 
especially since Simon is telling us he's going to go ahead with that work 
whether or not it ends up also being the SASL WG's work product.

So, it seems highly likely there will be a GSS-API password mech.  Any such 
mech would have to go to some effort _not_ to work with GS2, which means 
that if we also do a SASL-only password mech, then there will be two 
independent password mechanisms that can be used with SASL.  That means we 
will have duplicated effort in developing those mechanisms, and there will 
be confusion among users, operators, and SASL application protocol 
designers and implementers as to which mechanism they should use.

Given all of that, I think everyone is best served by merging Simon's 
effort with SCRAM and producing a single mechanism which has the best 
properties of both, including the ability to be used as a GSS-API mechanism 
and a clear enough specification that it is possible to do a direct-to-SASL 
implementation without requiring a GSS-API library or an inderstanding of 
how GSS-API works.


> SCRAM isn't a GSS-API mechanism, as far as I know, so it fails the first
> criteria I had when writing my password-auth document.  I must admit
> that I haven't reviewed SCRAM since it was initially discussed.  Where
> can I find the latest SCRAM document?
>
> For reference, the latest version of my password document is available
> from <http://josefsson.org/password/>.

If you're going to continue this effort, I do think you should continue to 
maintain it as an internet-draft, where it can be easily found.  I also 
think that if the SASL WG ends up deciding to produce a SASL-only 
mechanism, you should pursue publishing your GSS-API mechanism on the 
standards-track via the individual submission process (i.e. find an AD to 
sponsor it).  While I would prefer to see a single mechanism that can be 
used with either framework, I believe that having two mechanisms would be 
preferable to not having a suitable password mechanism for GSS-API.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE01CI010178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 07:00:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BE0148010177; Tue, 11 Mar 2008 07:00:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BDxx12010127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 07:00:00 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JZ51F-0000Xm-Fd for [e-mail]; Tue, 11 Mar 2008 13:59:53 +0000
Received: from hmbg-d9b88e36.pool.mediaways.net ([217.184.142.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 13:59:53 +0000
Received: from nobody by hmbg-d9b88e36.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 13:59:53 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: which is our DIGEST-MD5 successor?
Date:  Tue, 11 Mar 2008 15:02:14 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 31
Message-ID: <fr638g$vgu$[e-mail]>
References:  <[e-mail]><[e-mail]> <fr51no$jdj$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e36.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>> Thanks, that uses HMAC-SHA-256 =3D> nothing for me.
> Could you elaborate why?

The short version:  My MD5 test suite is about MD5,
all MD5 examples in RFCs I'm aware of:
<http://omniplex.blogspot.com/2008/03/md5-16-pop3-and-uuid.html>

A somewhat longer version:  I don't trust SHA-*, I
think that folks wanting SHA-* claiming that it is
"better" often miss more than one point, I don't
have the 30..100K USD for a certificate (see SAAG
thread), and I don't like the SHA-* patent. =20

That's as far as "for fun" is concerned, I'd have
no problem with implementing SHA-* professionally,
or using a certified library.  But I'd still ask
in what sense SHA-256 is "better" apart from the
obvious "twice as nothing happens" for 256=3D2*128.

Also a point in SCRAM, but I didn't check if it is
still there, does MD5( ... MD5( x ) ... ) make=20
sense, apart from burning time ?  Why not simply
use MD5( counter || x ) instead of MD5^n( x ) ?

One nice property of MD5, I have vague ideas about
its limitations, e.g., nobody ever said that it is
suited to produce pseudo random numbers. =20

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BDSpn2006772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 06:28:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BDSpe7006771; Tue, 11 Mar 2008 06:28:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BDSnXg006757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 11 Mar 2008 06:28:50 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2BDSX5D003503; Tue, 11 Mar 2008 09:28:34 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m2BDSSHQ006588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 09:28:28 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m2BDSRKr012589; Tue, 11 Mar 2008 09:28:27 -0400 (EDT)
To: Simon Josefsson <[e-mail]>
Cc: "Frank Ellermann" <[e-mail]>, [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
References: <[e-mail]> <[e-mail]> <fr51no$jdj$[e-mail]> <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Tue, 11 Mar 2008 09:28:27 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Tue, 11 Mar 2008 12:43:19 +0100")
Message-ID: <[e-mail]>
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson <[e-mail]> writes:

> Thanks.  SCRAM is not a GSS-API mechanism as far as I can tell, so I
> believe we have different goals.  I guess it is up to the WG to decide
> whether to base the password mechanism on GSS-API or not.

We have consensus to attempt making the new password-based mechanism a
valid GS2 mechanism (and thus also a valid GSS-API mechanism), only
specifying it in a way allowing for implementation without reference
to the GSS-API specs.

---Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BBhap3096191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 04:43:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BBhaSZ096190; Tue, 11 Mar 2008 04:43:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BBhVvE096183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 11 Mar 2008 04:43:35 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2BBhK6B031107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 12:43:24 +0100
From: Simon Josefsson <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
References: <[e-mail]> <[e-mail]> <fr51no$jdj$[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080311:[e-mail]::xDyFc52Bbgmzc1IA:0W/z
X-Hashcash: 1:22:080311:[e-mail]::ickvAkB4mnyAxh3s:APi7
Date: Tue, 11 Mar 2008 12:43:19 +0100
In-Reply-To: <fr51no$jdj$[e-mail]> (Frank Ellermann's message of "Tue, 11 Mar 2008 05:30:06 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Frank Ellermann" <[e-mail]> writes:

> Simon Josefsson wrote:
>
>> Where can I find the latest SCRAM document?
>
> <http://tools.ietf.org/html/scram> is a trick to find
> drafts "by name", also nice as an "opensearch" form.
>
> In draft-newman-auth-scram-05 appendix C (examples)
> is still empty.

Thanks.  SCRAM is not a GSS-API mechanism as far as I can tell, so I
believe we have different goals.  I guess it is up to the WG to decide
whether to base the password mechanism on GSS-API or not.

>> the latest version of my password document is
>> available from <http://josefsson.org/password/>.
>
> Thanks, that uses HMAC-SHA-256 => nothing for me.

Could you elaborate why?  Supporting HMAC-SHA-1 or even HMAC-MD5 would
be easy, and the reason for picking HMAC-SHA-256 was rather arbitrary.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2B4Ru8q041318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 21:27:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2B4RuhG041317; Mon, 10 Mar 2008 21:27:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2B4RmMP041304 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 10 Mar 2008 21:27:54 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JYw5b-0006wf-IG for [e-mail]; Tue, 11 Mar 2008 04:27:47 +0000
Received: from hmbg-d9b88e36.pool.mediaways.net ([217.184.142.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 04:27:47 +0000
Received: from nobody by hmbg-d9b88e36.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 11 Mar 2008 04:27:47 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: which is our DIGEST-MD5 successor?
Date:  Tue, 11 Mar 2008 05:30:06 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 16
Message-ID: <fr51no$jdj$[e-mail]>
References:  <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e36.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

> Where can I find the latest SCRAM document?

<http://tools.ietf.org/html/scram> is a trick to find
drafts "by name", also nice as an "opensearch" form.

In draft-newman-auth-scram-05 appendix C (examples)
is still empty.
=20
> the latest version of my password document is
> available from <http://josefsson.org/password/>.

Thanks, that uses HMAC-SHA-256 =3D> nothing for me.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AMlsUm003983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 15:47:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AMlsmS003982; Mon, 10 Mar 2008 15:47:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AMllvp003968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 10 Mar 2008 15:47:52 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2AMlgj2022320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 23:47:42 +0100
From: Simon Josefsson <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: which is our DIGEST-MD5 successor?
In-Reply-To: <[e-mail]> (Tom Yu's message of "Mon, 10 Mar 2008 16:58:40 -0400")
References: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080310:[e-mail]::MUr3UHwoF0kVDMqO:5et8
X-Hashcash: 1:22:080310:[e-mail]::PCnfEISRcip0QPhm:e+EN
Date: Mon, 10 Mar 2008 23:47:42 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu <[e-mail]> writes:

> We have had several password-based SASL mechanism proposals submitted
> to the WG for the purpose of replacing DIGEST-MD5.  Much of our
> discussion has centered on SCRAM, but I would like to make sure that
> we have consensus behind SCRAM and that all proposals presented to us
> have been adequately considered.
>
> I believe the HEXA proposal has been merged into SCRAM.  Simon
> Josefsson has also submitted a password-based mechanism.  During
> IETF70, I had misunderstood Simon's intention with this document and
> believed that he was withdrawing it.  Simon has since stated that he
> intends to continue pursuing his document.  The document remains
> expired, as far as I can tell, so this may not be relevant anymore.
> (Simon, do you intend to renew the document?)

Let me clarify: given that there weren't much interest from the SASL
community, I didn't think there were any point in describing the SASL
mappings of the GSS-API mechanism that my document specifies.  I may
have said that I would retire that part of the document.  My intention
is still to pursue the rest of the document as a normal GSS-API
mechanism.  I always wanted it possible to use the mechanism with GS2,
and when implementing I would probably use that as the first test case.

I do intend to pursue the GSS-API mechanism part of that document, but
alas haven't had time to implement it yet.  My document doesn't
necessarily have to be an IETF document though.  If SCRAM evolves into a
GSS-API mechanism, I would consider to use that instead, and drop my
proposal.  Or we could merge SCRAM and my draft, if people can agree on
the design.  My requirements are that it should be a GSS-API mechanism
and that it should use hashing, and not be specific to the SASL context.
I don't think I have other strong requirements.

A SASL-specific password-mechanism is likely to be simpler than a
GSS-API mechanism from a specification complexity point of view.  If
people want a dead simple SASL password mechanism specification that do
not mention GSS-API, I don't think that approach is compatible with my
goals.  Then we'll end up with two solutions for these two different
goals.

> I think Chris Newman said during the WG session at IETF70 that he
> believed there was nothing in Simon's document that was not in SCRAM,
> apart from a few paragraphs about making the protocol consistent with
> GS2.  I later realized that Chris is listed as an author of SCRAM, and
> would like additional opinions.

SCRAM isn't a GSS-API mechanism, as far as I know, so it fails the first
criteria I had when writing my password-auth document.  I must admit
that I haven't reviewed SCRAM since it was initially discussed.  Where
can I find the latest SCRAM document?

For reference, the latest version of my password document is available
from <http://josefsson.org/password/>.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AL5GSL092144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 14:05:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AL5GZ7092143; Mon, 10 Mar 2008 14:05:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AL5E3Z092136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 10 Mar 2008 14:05:15 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m2AL58wi022245 for <[e-mail]>; Mon, 10 Mar 2008 17:05:13 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m2AKweX1024558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 10 Mar 2008 16:58:41 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m2AKwekP028988; Mon, 10 Mar 2008 16:58:40 -0400 (EDT)
To: [e-mail]
Subject: which is our DIGEST-MD5 successor?
From: Tom Yu <[e-mail]>
Date: Mon, 10 Mar 2008 16:58:40 -0400
Message-ID: <[e-mail]>
Lines: 27
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We have had several password-based SASL mechanism proposals submitted
to the WG for the purpose of replacing DIGEST-MD5.  Much of our
discussion has centered on SCRAM, but I would like to make sure that
we have consensus behind SCRAM and that all proposals presented to us
have been adequately considered.

I believe the HEXA proposal has been merged into SCRAM.  Simon
Josefsson has also submitted a password-based mechanism.  During
IETF70, I had misunderstood Simon's intention with this document and
believed that he was withdrawing it.  Simon has since stated that he
intends to continue pursuing his document.  The document remains
expired, as far as I can tell, so this may not be relevant anymore.
(Simon, do you intend to renew the document?)

I think Chris Newman said during the WG session at IETF70 that he
believed there was nothing in Simon's document that was not in SCRAM,
apart from a few paragraphs about making the protocol consistent with
GS2.  I later realized that Chris is listed as an author of SCRAM, and
would like additional opinions.

Has anyone other than Chris looked at Simon's document and concluded
that Simon's document is substantially feature-equivalent to SCRAM,
except for the few paragraphs about GS2 compatibility?  We can discuss
this during the WG session tomorrow, but getting some discussion
started on the mailing list in advance would also be useful.

---Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26GxBoX052019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 09:59:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26GxB1Z052018; Thu, 6 Mar 2008 09:59:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26Gx8U0052010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Mar 2008 09:59:10 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] ([75.141.230.206]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m26Gx6ei099191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Thu, 6 Mar 2008 16:59:07 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Clarifying the qualities we desire the DIGEST-MD5 replacement to have
Date: Thu, 6 Mar 2008 08:59:06 -0800
X-Mailer: Apple Mail (2.919.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m250fuPO002612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 17:41:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m250fuQu002611; Tue, 4 Mar 2008 17:41:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m250fk35002587 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 4 Mar 2008 17:41:52 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JWhhU-00066P-1y for [e-mail]; Wed, 05 Mar 2008 00:41:40 +0000
Received: from hmbg-d9b88e2b.pool.mediaways.net ([217.184.142.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 05 Mar 2008 00:41:40 +0000
Received: from nobody by hmbg-d9b88e2b.pool.mediaways.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 05 Mar 2008 00:41:40 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Digest-MD5 to Historic
Date:  Wed, 5 Mar 2008 01:43:55 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 128
Message-ID: <fqkq7r$klm$[e-mail]>
References:  <[e-mail]> <[e-mail]> <fop89f$6m2$[e-mail]> <fpm5f5$53e$[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: hmbg-d9b88e2b.pool.mediaways.net
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> it should be "algorithm" instead of "alg"

Plus s/authz/authzid/g, and a bunch of parameters I have
forgotten, <charset>, <stale>, <cipher>, <maxbuf>, maybe
more.  I also forgot to add a 2617-version of the example
in RFC 5034.

It is probably more straightforward to focus on one issue,
RFC 2617 and 2831 md5-sess are incompatible, see below for
a fresh and far shorter attempt.

Apparently DIGEST-MD5 is also used for BEEP.  How sure are
you that deprecating RFC 2831 is okay ?  Should RFC 2617
with its different md5-sess idea added to the registry of
SASL mechanisms under another name ? =20

 Frank

-----------------------------------------------------------------
Omitting plausibility checks and parameter parsing, as well as
all details of  XURI =3D <method> ":" <uri> [":" <hash>]  the code
(here using REXX) for DIGEST-MD5 could be something like this:

   parse arg USER, PASS, REALM, NONCE, CNONCE, NC, QOP, XURI, ALG
   ALG =3D translate( ALG )        /* algorithm is case insensitive */

   HA1 =3D MD5(  USER || ':' || REALM || ':' || PASS )
   if ALG =3D 'MD5-SESS'  then  do
      HA1 =3D x2c( HA1 ) || ':' || NONCE || ':' || CNONCE
      if arg( 10, 'e' ) then  HA1 =3D HA1 || ':' || arg( 10 )
      HA1 =3D MD5( HA1 )           /* optional 10th arg.: AUTHZID   */
   end

   HA2 =3D MD5( XURI )             /* XURI incl. hash for auth-int  */
   TMP =3D NONCE                   /* 2069 compatibility (=3D no qop) */
   if ALG =3D 'MD5-SESS' | QOP <> ''  then  do
      TMP =3D translate( d2x( NC, 8 ), 'abcdef', 'ABCDEF' )
      TMP =3D NONCE || ':' || TMP || ':' || CNONCE || ':' || QOP
   end

   return MD5( HA1 || ':' || TMP || ':' || HA2 )

Here MD5( x ) is a subroutine returning 32 lower case hex. digits
of the MD5 [RFC 1321].  Ideally this code should also work for an
HTTP Auth Digest [RFC 2617].  Unfortunately this is not the case
for 'MD5-SESS':  [RFC 2831] adopted the [RFC 2617] algorithms "as
is" before the 'MD5-SESS' erratum was reported.  One line in the
example code shown above has to be modified:

      HA1 =3D HA1 || ':' || NONCE || ':' || CNONCE

The difference is x2c( HA1 ) vs. HA1.  In other words [RFC 2831]
uses a binary MD5 where [RFC 2617] plus erratum uses a hex. MD5
string.  See the expired [I-D.smith-sipping-auth-01] for correct
2069-fallback and 'MD5-SESS' examples.

New "fixed" [RFC 2617] 'MD5-SESS' results for examples published
in [RFC 2831], [RFC 4643], and [RFC 5034] are shown below:

1: user   =3D "chris" (see RFC 2831)
   pass   =3D "secret"
   realm  =3D "elwood.innosoft.com"
   method =3D "AUTHENTICATE"
   uri    =3D "imap/elwood.innosoft.com"
   nonce  =3D "OA6MG9tEQGm2hh"
   qop    =3D "auth"
   cnonce =3D "OA6MHXh6VqTrRk"
   nc     =3D 1
   alg    =3D "md5-sess"

   RFC 2831 digest  =3D "d388dad90d4bbd760a152321f2143af7"
   RFC 2831 rspauth =3D "ea40f60335c427b5527b84dbabcdfffd"

   RFC 2617 digest  =3D "26ef1190b643a36e879673066098379c"
   RFC 2617 rspauth =3D "c316c87a595a2cbfb4405784db016e34"

2: user   =3D "chris" (see RFC 2831)
   pass   =3D "secret"
   realm  =3D "elwood.innosoft.com"
   method =3D "AUTHENTICATE"
   uri    =3D "acap/elwood.innosoft.com"
   nonce  =3D "OA9BSXrbuRhWay"
   qop    =3D "auth"
   cnonce =3D "OA9BSuZWMSpW8m"
   nc     =3D 1
   alg    =3D "md5-sess"

   RFC 2831 digest  =3D "6084c6db3fede7352c551284490fd0fc"
   RFC 2831 rspauth =3D "2f0b3d7c3c2e486600ef710726aa2eae"

   RFC 2617 digest  =3D "90771dc5643a801bb9a9bcbb1ed3cd34"
   RFC 2617 rspauth =3D "ec0700b2da00dd133bcb0c841f42d341"

3: user   =3D "test"  (see RFC 4643)
   pass   =3D "test"
   realm  =3D "eagle.oceana.com"
   method =3D "AUTHENTICATE"
   uri    =3D "nntp/localhost"
   nonce  =3D "sayAOhCEKGIdPMHC0wtleLqOIcOI2wQYIe4zzeAtuiQ=3D"
   qop    =3D "auth-conf"
   cnonce =3D "0Y3JQV2Tg9ScDip+O1SVC0rhVg//+dnOIiGz/7CeNJ8=3D"
   nc     =3D 1
   alg    =3D "md5-sess"
   hash   =3D "00000000000000000000000000000000"

   RFC 2831 digest  =3D "d43cf66cffa903f9eb0356c08a3db0f2"
   RFC 2831 rspauth =3D "de2e127e5a81cda53d97acda35cde83a"

   RFC 2617 digest  =3D "41e814138958b1a0f08ef8b2dbe94ee9"
   RFC 2617 rspauth =3D "3f4d2b034c67c0c77df650f34ece6127"

4: user   =3D "chris" (see RFC 5034)
   pass   =3D "secret"
   realm  =3D "elwood.innosoft.com"
   method =3D "AUTHENTICATE"
   uri    =3D "pop/elwood.innosoft.com"
   nonce  =3D "OA6MG9tEQGm2hh"
   qop    =3D "auth"
   cnonce =3D "OA6MHXh6VqTrRk"
   nc     =3D 1
   alg    =3D "md5-sess"

   RFC 2831 digest  =3D "b0d56d2f054c24b62072322106468db9"
   RFC 2831 rspauth =3D "0b971462cef5e8f930db9a33b02fc9a0"

   RFC 2617 digest  =3D "089a19fffd2d75667e9d01583ee0fd58"
   RFC 2617 rspauth =3D "bb52468bdaadaac994e05c3958c71a09"