Re: New GS2 design -- much simplified, and simplified SCRAM

[Nicolas Williams <[e-mail]>]

On Sat, Feb 28, 2009 at 11:13:51PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Jeff's right: we need a consensus call on whether or not to bother 
> >with sec layers.
> 
> Before that, I'd like to know whether security layers will be DOA. Why 
> haven't they gotten more deployment before, and does SCRAM repeat 
> whatever the reasons were?

Russ Allbery explained one reason: using security layers means passing
all I/O through SASL functions, and that's just obnoxious, particularly
when it has to be done again for TLS, thus some app developers don't
seem to bother.

This has nothing to do with mechanism design mistakes.

I know of several apps that use SASL/GSSAPI sec layers just fine.  But
it's not examples of such apps that we need, we need examples of apps
that don't support sec layers.

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 n1SMiCM6055456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 15:44:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SMiC1U055455; Sat, 28 Feb 2009 15:44:12 -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 n1SMiB2k055448 for <[e-mail]>; Sat, 28 Feb 2009 15:44:11 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1SMiB7D013706 for <[e-mail]>; Sat, 28 Feb 2009 22:44:11 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 n1SMiAnN026153 for <[e-mail]>; Sat, 28 Feb 2009 15:44:11 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1SMRfIJ011377; Sat, 28 Feb 2009 16:27:41 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1SMRf0l011376; Sat, 28 Feb 2009 16:27:41 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 28 Feb 2009 16:27:41 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail], Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Sat, Feb 28, 2009 at 11:13:51PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Jeff's right: we need a consensus call on whether or not to bother 
> >with sec layers.
> 
> Before that, I'd like to know whether security layers will be DOA. Why 
> haven't they gotten more deployment before, and does SCRAM repeat 
> whatever the reasons were?

Russ Allbery explained one reason: using security layers means passing
all I/O through SASL functions, and that's just obnoxious, particularly
when it has to be done again for TLS, thus some app developers don't
seem to bother.

This has nothing to do with mechanism design mistakes.

I know of several apps that use SASL/GSSAPI sec layers just fine.  But
it's not examples of such apps that we need, we need examples of apps
that don't support sec layers.

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 n1SMCXEI054376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 15:12:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SMCXW8054375; Sat, 28 Feb 2009 15:12:33 -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 n1SMCLhP054364 for <[e-mail]>; Sat, 28 Feb 2009 15:12:32 -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 D401C4AC6D; Sat, 28 Feb 2009 23:12:20 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1235859140-22117-1/6/67 (6 recipients); Sat, 28 Feb 2009 23:12:20 +0100
Message-Id: <[e-mail]>
Date: Sat, 28 Feb 2009 23:13:51 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Cc: Alexey Melnikov <[e-mail]>, [e-mail], Dave Cridland <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Nicolas Williams writes:
> Jeff's right: we need a consensus call on whether or not to bother 
> with sec layers.

Before that, I'd like to know whether security layers will be DOA. Why 
haven't they gotten more deployment before, and does SCRAM repeat 
whatever the reasons were?

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 n1SLt7WJ053543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 14:55:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SLt7xW053542; Sat, 28 Feb 2009 14:55:07 -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 n1SLt524053536 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Sat, 28 Feb 2009 14:55:06 -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 n1SLt5c8027317 for <[e-mail]>; Sat, 28 Feb 2009 21:55:05 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 n1SLt51L001674 for <[e-mail]>; Sat, 28 Feb 2009 14:55:05 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1SLcYZU011338; Sat, 28 Feb 2009 15:38:34 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1SLcXEU011337; Sat, 28 Feb 2009 15:38:33 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 28 Feb 2009 15:38:33 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail], Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Sat, Feb 28, 2009 at 09:25:52PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >SASL must handle max buffer negotiation and security layers negotiation,
> >right?  That's why I have that in GS2.  It means not having to have it
> >in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).
> >
> No, it is not a bug. A SASL mechanism may choose not to provide any 
> security layer. But if it does, it must allow negotiation of the max 
> buffer size.

Most who have commented since seem to be saying we don't want SCRAM to
have sec layers -- that we must always do channel binding.

Jeff's right: we need a consensus call on whether or not to bother with
sec layers.

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 n1SLQJvY052497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 14:26:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SLQJIC052496; Sat, 28 Feb 2009 14:26:19 -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 n1SLQHl6052489 for <[e-mail]>; Sat, 28 Feb 2009 14:26:18 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.239.52] (92.40.239.52.sub.mbb.three.co.uk [92.40.239.52])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 28 Feb 2009 21:26:15 +0000
Message-ID: <[e-mail]>
Date: Sat, 28 Feb 2009 21:25:52 +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: Nicolas Williams <[e-mail]>
CC: [e-mail], Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Nicolas Williams wrote:

>On Fri, Feb 27, 2009 at 03:34:14PM -0800, [e-mail] wrote:
>  
>
>>>These aren't all exactly constants, but the variability is minimal.      
>>>
>>Hmm. Well, it's a fair bit more variability that I'd like to see in there. So
>>this is really going to boil down to specsmanship and whether or not
>>it can be described in a way that's sufficiently clear all the GS2
>>stuff doesn't appear so unwieldy. Perhaps some sort of quickstart
>>guide on how to set all this stuff in the non-GSS-API case would help.
>>
>
>With the changes I describe below we have a single field that's likely
>to be variable: the security layers request from.
>
>SASL must handle max buffer negotiation and security layers negotiation,
>right?  That's why I have that in GS2.  It means not having to have it
>in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).
>
No, it is not a bug. A SASL mechanism may choose not to provide any 
security layer. But if it does, it must allow negotiation of the max 
buffer size.

>RFC4422 doesn't seem to REQUIRE that max buffers/sec layers be
>negotiable.  We clearly want negotiable sec layers, and negotiable
>channel binding.
>
Right.

>We don't necessarily want negotiable max buffer.
>
I think that would be a mistake. This feature is important, as it allows 
the client to control its memory usage.

>The flag indicating whether channel binding was done can actually be
>removed, since the server can try to validate the client's HMAC both
>ways, with and without channel binding.  And since that flag effectively
>gets duplicated in the mech name I think I can just remove that flag.
>  
>
Sure.

>By having a reasonable minimum max buffer and by requiring that the
>server allow "none" and "integrity" sec layers (when the mechanism
>supports integrity sec layers) we can also make sure that a SCRAM client
>never triggers server rejection of the client's proposals.  That turns
>one more byte into a constant and removes one alternative.
>  
>
Right.



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 n1SKdn4Z050676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 13:39:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SKdnY1050675; Sat, 28 Feb 2009 13:39:49 -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 n1SKdc8q050667 for <[e-mail]>; Sat, 28 Feb 2009 13:39:49 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.239.52] (92.40.239.52.sub.mbb.three.co.uk [92.40.239.52])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 28 Feb 2009 20:39:36 +0000
Message-ID: <[e-mail]>
Date: Sat, 28 Feb 2009 20:39:21 +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: Paul Romero <[e-mail]>
CC: [e-mail]
Subject: Re: LOGIN mechanism: Standards Status
References: <[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>

Paul Romero wrote:

>Hi Folks:
>  
>
Hi Paul,

>Does anybody have information about the standards status
>and use of the LOGIN mechanism relative to RFC 2554
>or 4954 ?
>  
>
There is no RFC documenting the LOGIN mechanism. There was a draft some 
time ago, but it has expired.

<http://www.melnikov.ca/mel/devel/SASL_ClientRef.html> gives a list of 
some clients using it.



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 n1SKUAfH050189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 13:30:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SKUAEQ050188; Sat, 28 Feb 2009 13:30:10 -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 n1SKU9LA050181 for <[e-mail]>; Sat, 28 Feb 2009 13:30:09 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1SKU9EF017229 for <[e-mail]>; Sat, 28 Feb 2009 20:30:09 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 n1SKU9IV037497 for <[e-mail]>; Sat, 28 Feb 2009 13:30:09 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1SKL8Uf011246; Sat, 28 Feb 2009 14:21:08 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1SKL8Qa011245; Sat, 28 Feb 2009 14:21:08 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 28 Feb 2009 14:21:08 -0600
From: Nicolas Williams <[e-mail]>
To: Russ Allbery <[e-mail]>
Cc: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Sat, Feb 28, 2009 at 12:07:04PM -0800, Russ Allbery wrote:
> In practice, the world seems to be converging on TLS for all transport
> security regardless of how one authenticates.  I think this is very
> unfortunate given that TLS is rather heavy, requires things like channel
> bindings that most programmers don't understand, requires maintaining a
> separate public key infrastructure, and is slower and more complicated
> than just negotiating a security layer as part of the authentication
> process, but I'm not sure any of us are going to be able to reverse the
> trend.

For an app programmer channel binding is actually simple: ask TLS for it
and give it to SASL.  Two function calls.  Passing the channel binding
to SASL can be done via a function call the app would have to do
anyways, so one function call.  The channel binding is an opaque octet
string requiring no interpretation by the app.

For a SCRAM implementor channel binding is also simple: add an
application-provided string as an input to one of the HMACs.

For TLS implementors it's also simple.  See the TLS channel binding
types registered at IANA.

I like where this is going.  Everyone seems to be saying "to hell with
sec layers" -- that simplifies GS2 enormously since it removes max
buffer and sec layer negotiation and leaves just that one RFC2743 header
compression constant.  The channel binding negotiation bits stay and
are needed whether or not GS2 is kept, so GS2 is really now just a
single boolean constant added to SCRAM.

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 n1SKMVBb049867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 13:22:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SKMUcH049866; Sat, 28 Feb 2009 13:22:30 -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 n1SKMKr0049858 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Sat, 28 Feb 2009 13:22:30 -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 n1SKMJMd026004 for <[e-mail]>; Sat, 28 Feb 2009 20:22:19 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 n1SKMJ6Y035161 for <[e-mail]>; Sat, 28 Feb 2009 13:22:19 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1SKDIkW011234 for <[e-mail]>; Sat, 28 Feb 2009 14:13:18 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1SKDIhP011233 for [e-mail]; Sat, 28 Feb 2009 14:13:18 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 28 Feb 2009 14:13:18 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Re: TLS channel bindings specification exists
Message-ID: <[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>

I should note that there are two TLS channel bindings specs that can
apply in a SASL situation.  Which begs the question: which one to use.

The TLS end-point channel binding has the property that it can be used
with TLS concentrators without modifying them.  But then, TLS end-point
channel binding is not always available.  Therefore the TLS end-point
channel binding should be preferred and thus used whenever it's
available.



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 n1SKCrdi049349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 13:12:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SKCrMb049348; Sat, 28 Feb 2009 13:12:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.lmi.net (shell.lmi.net [66.117.140.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1SKCgJi049308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 28 Feb 2009 13:12:52 -0700 (MST) (envelope-from [e-mail])
Received: from rcom-software.com (ftp.rcom-software.com [75.101.82.95]) by shell.lmi.net (8.14.1/8.14.1) with ESMTP id n1SKCeAp070083 for <[e-mail]>; Sat, 28 Feb 2009 12:12:40 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 28 Feb 2009 12:13:59 -0800
From: Paul Romero <[e-mail]>
Organization: RCOM Communications Software
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,es,de-DE,fr-FR
MIME-Version: 1.0
To: [e-mail]
Subject: LOGIN mechanism: Standards Status
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.37
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>

Hi Folks:

Does anybody have information about the standards status
and use of the LOGIN mechanism relative to RFC 2554
or 4954 ?

Best Regards,

Paul R.


--
Paul Romero

RCOM Communications Software

Phone/Fax: [phone]
E-Mail: [e-mail]




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 n1SK7G8V048944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 13:07:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SK7GBO048943; Sat, 28 Feb 2009 13:07:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1SK75hn048932 for <[e-mail]>; Sat, 28 Feb 2009 13:07:15 -0700 (MST) (envelope-from [e-mail])
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E822E170955 for <[e-mail]>; Sat, 28 Feb 2009 12:07:04 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp1.stanford.edu (Postfix) with ESMTP id 7ECBB170931 for <[e-mail]>; Sat, 28 Feb 2009 12:07:04 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 474A5E9C1F; Sat, 28 Feb 2009 12:07:04 -0800 (PST)
To: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-Reply-To: <[e-mail]> (Arnt Gulbrandsen's message of "Sat\, 28 Feb 2009 12\:51\:50 +0100")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Russ Allbery <[e-mail]>
Organization: The Eyrie
Date: Sat, 28 Feb 2009 12:07:04 -0800
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>

Arnt Gulbrandsen <[e-mail]> writes:

> SASL security layers haven't succeeded. I don't know why. If you know
> the reasons why, and they don't apply to SCRAM (as implemented by
> randoms, not by ietf-sasl regulars), then fine. Otherwise it's just a
> dead feature.

OpenLDAP clients implement SASL security layers, but that isn't an
end-user client with a UI so it probably doesn't count for what you're
trying to measure.  Even the e-mail clients that implement GSSAPI
authentication inside SASL almost universally don't make use of the
negotiated security layer, which has caused us all sorts of heartburn.

I suspect the reason why is that it requires hooking the authentication
protocol into the network transport calls for the rest of the application,
which is significantly more complex than just having a set of pluggable
authentication modules that you can fire and forget.

TLS of course also requires the same thing, but unfortunately clients
don't seem to implement SASL security layers at the same time that they
implement TLS.  (Which is very unfortunate, since both require touching
the same code and it's fairly easy to do both at the same time, provided
that you can work out the internal API to hook into your authentication
providers.)

In practice, the world seems to be converging on TLS for all transport
security regardless of how one authenticates.  I think this is very
unfortunate given that TLS is rather heavy, requires things like channel
bindings that most programmers don't understand, requires maintaining a
separate public key infrastructure, and is slower and more complicated
than just negotiating a security layer as part of the authentication
process, but I'm not sure any of us are going to be able to reverse the
trend.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 n1SK2fhR048805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 13:02:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SK2fwH048804; Sat, 28 Feb 2009 13:02:41 -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 n1SK2dsQ048798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Sat, 28 Feb 2009 13:02:40 -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 n1SK2dW5010358 for <[e-mail]>; Sat, 28 Feb 2009 20:02:39 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 n1SK2c1A025367 for <[e-mail]>; Sat, 28 Feb 2009 13:02:39 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1SJccHE011203; Sat, 28 Feb 2009 13:38:38 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1SJcajA011202; Sat, 28 Feb 2009 13:38:36 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 28 Feb 2009 13:38:36 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Jeffrey Hutzelman <[e-mail]>, Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Sat, Feb 28, 2009 at 12:51:50PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Chris said that he wants channel binding and no sec layers, but later 
> >it was pointed out that not every implementor is ready to do channel 
> >binding to TLS at this time, so I *think* we have consensus that 
> >SCRAM should provide at least an integrity sec layer.
> 
> SASL security layers haven't succeeded. I don't know why. If you know 
> the reasons why, and they don't apply to SCRAM (as implemented by 
> randoms, not by ietf-sasl regulars), then fine. Otherwise it's just a 
> dead feature.

Never minding the fact that I use them...  This is what SCRAM/GS2 would
look like without sec layer support in GS2:

      C: Request authentication exchange (not a GS2 message, but a SASL
one)                                                        
      S: Empty Challenge                                                                                                            
      C: T  n=Chris Newman,r=ClientNonce                                                                               
         ^  ----------------------------
         |     SCRAM message
	 |
	 GS2 field compressing the RFC2743 header; constant for SCRAM

         The channel bindings data will have been:

            SCRAM-CB T <actual TLS channel binding, if any>
            ^^^^^^^^ ^
            |        |
            |        A copy of the header in front of SCRAM                                                                    
            |                                                                                                                       
            |                                                                                                                       
            Mech name, effectively constant, provided by the app and
            likely taken from server's SASL mech list.

      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         -------------------------------------------
            SCRAM message                                                                                                   

      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
         -------------------------------------------------------------
            SCRAM message
      S: v=WxPv/siO5l+qxN4
         -----------------
            SCRAM message
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

That means:

 - A single constant is used as a header to just one SCRAM message.

 - The mechanism name and a constant is used as a header to the channel
   binding data.

 - We still have two mechanism names: the server advertises only one of
   them, indicating whether the server supports channel binding.

   This and putting the mechname used into the channel binding is NOT an
   artifact of GS2 -- a pure SASL SCRAM would still need this.

The channel binding flag is gone -- the server can try to validate the
client's HMAC both, with and without channel binding data (but always
with the GS2 channel binding header).

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 n1SJqHp9048392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 12:52:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SJqHho048391; Sat, 28 Feb 2009 12:52:17 -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 n1SJq62M048380 for <[e-mail]>; Sat, 28 Feb 2009 12:52:16 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1SJq5ts009430 for <[e-mail]>; Sat, 28 Feb 2009 19:52:05 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 n1SJq59x020828 for <[e-mail]>; Sat, 28 Feb 2009 12:52:05 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1SJRvWD011195; Sat, 28 Feb 2009 13:27:57 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1SJRsAS011194; Sat, 28 Feb 2009 13:27:54 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 28 Feb 2009 13:27:54 -0600
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], [e-mail], Arnt Gulbrandsen <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <15219.1235820001.492969@invsysm1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15219.1235820001.492969@invsysm1>
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 Sat, Feb 28, 2009 at 11:20:01AM +0000, Dave Cridland wrote:
> On Sat Feb 28 04:24:10 2009, Nicolas Williams wrote:
> >Chris said that he wants channel binding and no sec layers, but  
> >later it
> >was pointed out that not every implementor is ready to do channel
> >binding to TLS at this time, so I *think* we have consensus that  
> >SCRAM
> >should provide at least an integrity sec layer.
> 
> I've seen a lot of DIGEST-MD5 implementations. I've seen quite a few  
> servers that offer security layers. I can only think of two clients  
> that actually use security layers - one of which is mine, and  
> probably used only by me, so I'm not sure that counts. This suggests  
> to me that security layers - whilst possibly desirable from a  
> theoretical standpoint - will be ignored in practise.

I have an LDAP application that uses SASL/GSS-API with security layers
all the time.

But sure, I second Jeff's call for a consensus on security layers.  If
we agree we don't want them, then several bits of the GS2 headers go
away.

> I agree that not every implementor will do TLS channel bindings. This  
> is enforced mostly by not yet having those defined - if we went for,  

Actually, they are defined!  Just not in an RFC, but in an IANA
registry:

http://www.iana.org/assignments/channel-binding-types/
http://www.iana.org/assignments/channel-binding-types/tls-server-end-point
http://www.iana.org/assignments/channel-binding-types/tls-unique
http://www.iana.org/assignments/channel-binding-types/tls-unique-for-telnet

> say, the concatenation of the client and Server finished messages in  
> that order, I can implement within the next ten minutes - I actually  
> have this code standing by.

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 n1SJprVQ048373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 12:51:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SJprmE048372; Sat, 28 Feb 2009 12:51:53 -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 n1SJpgRf048349 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Sat, 28 Feb 2009 12:51:52 -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 n1SJpfZ6008481 for <[e-mail]>; Sat, 28 Feb 2009 19:51:41 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 n1SJpfu7020718 for <[e-mail]>; Sat, 28 Feb 2009 12:51:41 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1SJge8K011209 for <[e-mail]>; Sat, 28 Feb 2009 13:42:40 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1SJgeGe011208 for [e-mail]; Sat, 28 Feb 2009 13:42:40 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 28 Feb 2009 13:42:40 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: TLS channel bindings specification exists
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

A while back someone asked and I said it wasn't done.  That was a
complete and total brainfart.  I should know better since I reviewed the
specifications that exist:

    http://www.iana.org/assignments/channel-binding-types/

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 n1SBoXZr025640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 04:50:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SBoX5M025639; Sat, 28 Feb 2009 04:50:33 -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 n1SBoLqX025626 for <[e-mail]>; Sat, 28 Feb 2009 04:50:31 -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 DB04C4AC6A; Sat, 28 Feb 2009 12:50:19 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1235821819-22117-1/6/64 (6 recipients); Sat, 28 Feb 2009 12:50:19 +0100
Message-Id: <[e-mail]>
Date: Sat, 28 Feb 2009 12:51:50 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Cc: [e-mail], Jeffrey Hutzelman <[e-mail]>, Dave Cridland <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Nicolas Williams writes:
> Chris said that he wants channel binding and no sec layers, but later 
> it was pointed out that not every implementor is ready to do channel 
> binding to TLS at this time, so I *think* we have consensus that 
> SCRAM should provide at least an integrity sec layer.

SASL security layers haven't succeeded. I don't know why. If you know 
the reasons why, and they don't apply to SCRAM (as implemented by 
randoms, not by ietf-sasl regulars), then fine. Otherwise it's just a 
dead feature.

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 n1SBKSx7023862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Feb 2009 04:20:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1SBKSUX023861; Sat, 28 Feb 2009 04:20:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1SBKG83023843 for <[e-mail]>; Sat, 28 Feb 2009 04:20:27 -0700 (MST) (envelope-from [e-mail])
Received: from invsysm1 (93-96-137-178.zone4.bethere.co.uk [93.96.137.178]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Sat, 28 Feb 2009 11:21:05 +0000
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <15219.1235820001.492969@invsysm1>
Date: Sat, 28 Feb 2009 11:20:01 +0000
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
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 Sat Feb 28 04:24:10 2009, Nicolas Williams wrote:
> Chris said that he wants channel binding and no sec layers, but  
> later it
> was pointed out that not every implementor is ready to do channel
> binding to TLS at this time, so I *think* we have consensus that  
> SCRAM
> should provide at least an integrity sec layer.

I've seen a lot of DIGEST-MD5 implementations. I've seen quite a few  
servers that offer security layers. I can only think of two clients  
that actually use security layers - one of which is mine, and  
probably used only by me, so I'm not sure that counts. This suggests  
to me that security layers - whilst possibly desirable from a  
theoretical standpoint - will be ignored in practise.

I agree that not every implementor will do TLS channel bindings. This  
is enforced mostly by not yet having those defined - if we went for,  
say, the concatenation of the client and Server finished messages in  
that order, I can implement within the next ten minutes - I actually  
have this code standing by.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



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 n1S4mPm2007479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 21:48:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1S4mPeG007478; Fri, 27 Feb 2009 21:48: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-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 n1S4mErH007469 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 27 Feb 2009 21:48:24 -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 n1S4mDaJ000721 for <[e-mail]>; Sat, 28 Feb 2009 04:48: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 n1S4mCiJ049256 for <[e-mail]>; Fri, 27 Feb 2009 21:48:12 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1S4OD2j010934; Fri, 27 Feb 2009 22:24:13 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1S4OA7Q010933; Fri, 27 Feb 2009 22:24:11 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 27 Feb 2009 22:24:10 -0600
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail], Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Fri, Feb 27, 2009 at 10:13:18PM -0500, Jeffrey Hutzelman wrote:
> The max buffer size is specifically the maximum amount of protected data 
> that can be sent in one security-layer message.  It doesn't have to be 
> negotiable, but if it is not, then GS2 must fix a value.
> 
> This, and the field used to negotiate use of a security layer, are _not_ 
> artifacts of GS2 or of trying to produce a dual-mode mechanism.  They are 
> purely requirements of producing a SASL mechanism which is capable of 
> negotiating these SASL features.  A GSS-API-only SCRAM would _not have_ 
> these fields, but a SASL-only SCRAM _would_ have them.
> 
> Unless...
> draft-newman-auth-scram-07.txt does not have these fields or their 
> equivalent, because it does not provide a security layer.  [...]
> [...]
> We really should come to a consensus once and for all as to whether SASL 
> security layers are a desirable feature or should be deprecated.  [...]

Chris said that he wants channel binding and no sec layers, but later it
was pointed out that not every implementor is ready to do channel
binding to TLS at this time, so I *think* we have consensus that SCRAM
should provide at least an integrity sec layer.

Which means that SCRAM will have to do at least sec layer negotiation,
and preferably also max buffer negotiation.  And since GS2 can provide
that, the complexity we're down to is really a bare minimum that we'll
have with or without GS2.

> >The flag indicating whether channel binding was done can actually be
> >removed, since the server can try to validate the client's HMAC both
> >ways, with and without channel binding.  And since that flag effectively
> >gets duplicated in the mech name I think I can just remove that flag.
> 
> That flag does _not_ get duplicated in the mech name.

No, I know, but for my purposes between the mech name and the fact that
the server can try to validate the HMAC twice it's good enough.  You
ought to let me get away with some simplifications, particularly when
you know I should know better (and I did) :)

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 n1S3DaLS004511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 20:13:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1S3DasT004510; Fri, 27 Feb 2009 20:13:36 -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 n1S3DOob004493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 27 Feb 2009 20:13:35 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-236-105.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1S3DI2p017882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 22:13:19 -0500 (EST)
Date: Fri, 27 Feb 2009 22:13:18 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, [e-mail]
cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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 Friday, February 27, 2009 06:03:57 PM -0600 Nicolas Williams 
<[e-mail]> wrote:

>
> On Fri, Feb 27, 2009 at 03:34:14PM -0800, [e-mail] wrote:
>> > These aren't all exactly constants, but the variability is minimal.
>>
>> Hmm. Well, it's a fair bit more variability that I'd like to see in
>> there. So this is really going to boil down to specsmanship and whether
>> or not it can be described in a way that's sufficiently clear all the GS2
>> stuff doesn't appear so unwieldy. Perhaps some sort of quickstart guide
>> on how to set all this stuff in the non-GSS-API case would help.
>
> With the changes I describe below we have a single field that's likely
> to be variable: the security layers request from.
>
> SASL must handle max buffer negotiation and security layers negotiation,
> right?  That's why I have that in GS2.  It means not having to have it
> in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).
>
> RFC4422 doesn't seem to REQUIRE that max buffers/sec layers be
> negotiable.  We clearly want negotiable sec layers, and negotiable
> channel binding.  We don't necessarily want negotiable max buffer.

The max buffer size is specifically the maximum amount of protected data 
that can be sent in one security-layer message.  It doesn't have to be 
negotiable, but if it is not, then GS2 must fix a value.

This, and the field used to negotiate use of a security layer, are _not_ 
artifacts of GS2 or of trying to produce a dual-mode mechanism.  They are 
purely requirements of producing a SASL mechanism which is capable of 
negotiating these SASL features.  A GSS-API-only SCRAM would _not have_ 
these fields, but a SASL-only SCRAM _would_ have them.

Unless...
draft-newman-auth-scram-07.txt does not have these fields or their 
equivalent, because it does not provide a security layer.  Nico's proposal 
in its current form causes GS2 to provide a security layer when used with 
any GSS-API mechanism that supports GSS_wrap(), including SCRAM.  If we 
were to decide that GS2 didn't need to provide a security layer, then this 
would all go away.  I'm not sure there is a clean way to make security 
layer negotiation go away for GS2-SCRAM while still having GS2 provide it 
for other mechanisms.


We really should come to a consensus once and for all as to whether SASL 
security layers are a desirable feature or should be deprecated.  If they 
are desirable, then we bite the bullet and include support for them, 
including negotation of max buffer size, in GS2 and SCRAM (regardless of 
whether we continue with Nico's proposal or abandon it and define SCRAM as 
a SASL-only mechanism).   If we decide security layers are deprecated, then 
rip them out of GS2 entirely, and this whole negotiation thing goes away.




> The flag indicating whether channel binding was done can actually be
> removed, since the server can try to validate the client's HMAC both
> ways, with and without channel binding.  And since that flag effectively
> gets duplicated in the mech name I think I can just remove that flag.

That flag does _not_ get duplicated in the mech name.

The mech name indicates whether the server is capable of supporting channel 
bindings; this _must_ be the same as the name the server actually 
advertised, and the server _must_ check that they are the same.  This is 
critical for the security of channel bindings, because it prevents an MITM 
attacker from forcing a downgrade when both sides actually support channel 
binding.

The flag in the message indicates whether the client actually sent channel 
binding data.  At first glance, it seems that this flag is redundant, since 
the HMAC will verify for at most one of the two possible CB data formats. 
However, it is required in the GS2 layer because GS2 only gets one chance 
to decide which CB data form it will pass to GSS_accept_sec_context().  You 
can't be sure you can just try the call a second time, because you need to 
provide the CB data starting on the first call, may not get the answer 
until the last call, and a multi-round-trip mechanism might produce tokens 
which cannot be replayed.  In fact, I could trivially construct a mechanism 
for which this would break, out of a pseudo-mechanism stacked above RFC4121.

I believe the channel-bindings-present flag has to stay.  Unless you want 
to abandon the semantics that allow authentication to succeed even when one 
side provides channel bindings data and the other does not, which sounds 
like asking for an interoperability problem.

Hint: sometimes interoperability means providing for negotiation.



> By having a reasonable minimum max buffer and by requiring that the
> server allow "none" and "integrity" sec layers (when the mechanism
> supports integrity sec layers) we can also make sure that a SCRAM client
> never triggers server rejection of the client's proposals.  That turns
> one more byte into a constant and removes one alternative.

Yes, one thing we can do is eliminate the server's ability to reject choice 
of security layer, instead requiring that it support everything the 
underlying GSS mechanism is capable of (for SCRAM, that means 'n' or 'i'). 
As you say, if we do that and fix the max buffer size, then we eliminate 
the possibility of extra round trips due to renegotiation of rejected 
options.  This also eliminates the need for the accept/reject flag on the 
server reply; if the client requests a security layer the mech doesn't 
support, then the server simply fails the authentication.

Then the exchange looks something like this:

C: <SASL request-auth>
S: <empty challenge>
C: nT+ n=Chris Newman,r=ClientNonce
S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
S: v=WxPv/siO5l+qxN4
C: <empty response>
S: <auth succeeds>

Where...
- Everything but the "nT+" on the client's first message is exactly
  as it would be in draft-newman-scram-auth
- "n" = no security layer (could be 'i' or 'p')
- "T" = channel bindings used (could be 'F' if not)
- "+" = GSS standard framing compression (fixed for SCRAM; could be '-'
        for GS2 with some non-standard GSS-API mechanism)
- The channel binding data looks like:
  "SCRAM-HMAC-SHA1-CB nT+ <TLS channel data>"


Without channel bindings, the client's first message contains nF+ instead 
of nT+, and the CB data is just "SCRAM-HMAC-SHA1-CB nF+".

If the server didn't support channel bindings (a fact which was advertised 
as part of the SASL mechanism name), then the client's first message always 
contains nF+ instead of nT+, and the CB data is "SCRAM-HMAC-SHA1-NC nF+".


-- 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 n1S0KiSt098430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 17:20:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1S0Kitb098429; Fri, 27 Feb 2009 17:20:44 -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 n1S0KViU098409 for <[e-mail]>; Fri, 27 Feb 2009 17:20:42 -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 n1S0KVCY024126 for <[e-mail]>; Sat, 28 Feb 2009 00:20:31 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 n1S0KVBF057976 for <[e-mail]>; Fri, 27 Feb 2009 17:20:31 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1S03wMN010739; Fri, 27 Feb 2009 18:03:58 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1S03vJD010738; Fri, 27 Feb 2009 18:03:57 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 27 Feb 2009 18:03:57 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Fri, Feb 27, 2009 at 03:34:14PM -0800, [e-mail] wrote:
> > These aren't all exactly constants, but the variability is minimal.
> 
> Hmm. Well, it's a fair bit more variability that I'd like to see in there. So
> this is really going to boil down to specsmanship and whether or not
> it can be described in a way that's sufficiently clear all the GS2
> stuff doesn't appear so unwieldy. Perhaps some sort of quickstart
> guide on how to set all this stuff in the non-GSS-API case would help.

With the changes I describe below we have a single field that's likely
to be variable: the security layers request from.

SASL must handle max buffer negotiation and security layers negotiation,
right?  That's why I have that in GS2.  It means not having to have it
in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).

RFC4422 doesn't seem to REQUIRE that max buffers/sec layers be
negotiable.  We clearly want negotiable sec layers, and negotiable
channel binding.  We don't necessarily want negotiable max buffer.

The flag indicating whether channel binding was done can actually be
removed, since the server can try to validate the client's HMAC both
ways, with and without channel binding.  And since that flag effectively
gets duplicated in the mech name I think I can just remove that flag.

By having a reasonable minimum max buffer and by requiring that the
server allow "none" and "integrity" sec layers (when the mechanism
supports integrity sec layers) we can also make sure that a SCRAM client
never triggers server rejection of the client's proposals.  That turns
one more byte into a constant and removes one alternative.

We're left with this:

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T  n=Chris Newman,r=ClientNonce
         --------------- ----------------------------
           GS2 header          SCRAM message
         ^^^^^^^^^^ ^ ^
         max buffer | |
         (can be    | |
          constant) | |
                    | |
                    | SCRAM, as a standard GSS mech, would have that
                    | RFC2743 header, thus we compress it as "T" here
                    | (is constant for SCRAM, always)
                    |
                    sec layer (none in this case) (can be constant)

         The channel bindings data will have been:

            SCRAM-CB 0x00002000 n T <actual TLS channel binding>
            ^^^^^^^^ ^^^^^^^^^^ ^ ^
            |        |          | |
            |        \          / /
            |         \        / /
            |          \      / /
            |           \    / /
            |            \  / /
            |             \/ /
            |             + /
	    |             |/
	    |             +
	    |             A copy of the header in front of SCRAM
            |
            |
            Mech name, effectively constant, provided by the app and
	    likely taken from server's SASL mech list.

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         ^ -------------------------------------------
         |          SCRAM message
         |
         GS2 header indicating that the server accepts the client's max
         buffer size and requested sec layers (constant if the client's
	 requested max buffer size is less than or equal to the minimum
	 max buffer size).

      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
         -------------------------------------------------------------
	 SCRAM message
      S: v=WxPv/siO5l+qxN4
         -----------------
	 SCRAM message
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)


The variant of the above without channel binding is trivial.

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 n1RNbDoa097033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 16:37:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RNbDDY097032; Fri, 27 Feb 2009 16:37:13 -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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RNbC6D097025 for <[e-mail]>; Fri, 27 Feb 2009 16:37:12 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 27 Feb 2009 15:37:06 -0800 (PST)
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]; Fri, 27 Feb 2009 15:36:53 -0800 (PST)
Date: Fri, 27 Feb 2009 15:34:14 -0800 (PST)
From: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-reply-to: "Your message dated Thu, 26 Feb 2009 13:31:57 -0600" <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail], Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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 Thu, Feb 26, 2009 at 10:54:54AM -0800, [e-mail] wrote:
> > Asuuming the GS2 headers here are constants, I think this is simple ehough.

> The GS2 headers contain:

> a) max buffer size, which is not really a constant, but which isn't all
>    that variable in practice;

>    (for apps that want channel binding this will be a constant as it's
>    not relevant if no sec layers are used)

> b) security layer proposals, which also are not really constants, and
>    also not that variable in practice;

>    (for apps that want channel binding this will be a constant, and for
>    apps that don't want channel binding this will be a constant in the
>    cases of SCRAM if we decide to provide only integrity protection)

> c) the mechanism name;

>    (for apps that want channel binding this is not a constant, but it
>    does come from listing the server's SASL mechs; for apps that don't
>    want channel binding this is as good as constant)

> c) a small handful of boolean flags:

>     - one is a constant in the SCRAM case (the RFC2743 compression flag);
>     - one is true if channel binding is in being done;
>     - and a flag to indicate server acceptance/rejection of client
>       maxbuf and sec layers proposals.

>    (for apps that keep to fixed maxbuf/channel binding proposals these
>    are as good as constant)

> These aren't all exactly constants, but the variability is minimal.

Hmm. Well, it's a fair bit more variability that I'd like to see in there. So
this is really going to boil down to specsmanship and whether or not
it can be described in a way that's sufficiently clear all the GS2
stuff doesn't appear so unwieldy. Perhaps some sort of quickstart
guide on how to set all this stuff in the non-GSS-API case would help.

				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 n1RGYbJR063298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 09:34:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RGYbJf063297; Fri, 27 Feb 2009 09:34:37 -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 n1RGYQ1s063278 for <[e-mail]>; Fri, 27 Feb 2009 09:34:37 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.101] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 27 Feb 2009 16:34:25 +0000
Message-ID: <[e-mail]>
Date: Fri, 27 Feb 2009 16:34:15 +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: Lyndon Nerenberg <[e-mail]>
CC: [e-mail]
Subject: Re: A dignified burial for CRAM-MD5
References: <[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>

Lyndon Nerenberg wrote:

>
> Folks, it has been nearly a decade since the first move towards 
> re-stating CRAM-MD5 as a SASL mechanism. It's obvious now that this 
> will never happen.
>
> It's also obvious that CRAM-MD5 has entrenched itself to the point 
> where it's not going to go away any time soon (or late for that matter).
>
> The global base of interoperable deployments says we don't need to 
> issue a formal update to the specification. Frankly, anything that 
> fits inside two pages of text and works this well deserves to be left 
> well enough alone.
>
> Since the SASL WG can't come to an agreement about the status of 
> CRAM-MD5 -- other than it's adamantly opposed to its moving forward on 
> the standards track -- I think it's time for the WG to drop CRAM-MD5 
> from the work list. It's currently not a formal SASL mechanism, so 
> abandonment by the WG is a valid solution.
>
> This would leave RFC2195 in its present state, validating the existing 
> CRAM-MD5 deployments. Beside that, I'm proposing to put together a new 
> Informational RFC that documents the WGs concerns about the mechanism, 
> and addresses the interoperability issues. (Kurt's draft has done much 
> of this work already.)

This works for me.



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 n1RGQTr0062867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 09:26:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RGQTu7062866; Fri, 27 Feb 2009 09:26:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.lmi.net (shell.lmi.net [66.117.140.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RGQSNm062860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 27 Feb 2009 09:26:29 -0700 (MST) (envelope-from [e-mail])
Received: from rcom-software.com (ftp.rcom-software.com [75.101.82.95]) by shell.lmi.net (8.14.1/8.14.1) with ESMTP id n1RGQDOO003351; Fri, 27 Feb 2009 08:26:21 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 27 Feb 2009 08:27:32 -0800
From: Paul Romero <[e-mail]>
Organization: RCOM Communications Software
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,es,de-DE,fr-FR
MIME-Version: 1.0
To: Tony Finch <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
References: <[e-mail]>    <[e-mail]>  <[e-mail]>   <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.37
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>

Hi Tony:

CRAM-MD5 only specifies that  passwords/secrets are to be used
as plaintext and not how they are stored.

Best Regards,

Paul R.


Tony Finch wrote:

> On Thu, 26 Feb 2009, Paul Romero wrote:
> >
> > It isn't obvious to me why PLAIN over TLS would be more prevalent than
> > CRAM-MD5.
>
> CRAM-MD5 requires plaintext passwords on the server but PLAIN does not.
> (i.e. PLAIN is compatible with Unix password files.)
>
> Tony.
> --
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
> MODERATE OR GOOD.

--
Paul Romero

RCOM Communications Software

Phone/Fax: [phone]
E-Mail: [e-mail]




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 n1RGH4Gs062261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 09:17:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RGH49m062260; Fri, 27 Feb 2009 09:17:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RGGqDM062252 for <[e-mail]>; Fri, 27 Feb 2009 09:17:03 -0700 (MST) (envelope-from [e-mail])
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45041) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1Ld5OL-0005Vu-3g (Exim 4.70) (return-path <[e-mail]>); Fri, 27 Feb 2009 16:16:49 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Ld5OL-00041M-3x (Exim 4.67) (return-path <[e-mail]>); Fri, 27 Feb 2009 16:16:49 +0000
Date: Fri, 27 Feb 2009 16:16:49 +0000
From: Tony Finch <[e-mail]>
X-X-Sender: [e-mail]
To: Paul Romero <[e-mail]>
cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>    <[e-mail]>  <[e-mail]>   <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
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 Thu, 26 Feb 2009, Paul Romero wrote:
>
> It isn't obvious to me why PLAIN over TLS would be more prevalent than
> CRAM-MD5.

CRAM-MD5 requires plaintext passwords on the server but PLAIN does not.
(i.e. PLAIN is compatible with Unix password files.)

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR 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 n1RFhiHu060112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 08:43:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RFhiq2060111; Fri, 27 Feb 2009 08:43:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.lmi.net (shell.lmi.net [66.117.140.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RFhXha060094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 27 Feb 2009 08:43:44 -0700 (MST) (envelope-from [e-mail])
Received: from rcom-software.com (ftp.rcom-software.com [75.101.82.95]) by shell.lmi.net (8.14.1/8.14.1) with ESMTP id n1RFhSZe001569; Fri, 27 Feb 2009 07:43:29 -0800 (PST)
Message-ID: <[e-mail]>
Date: Fri, 27 Feb 2009 07:44:46 -0800
From: Paul Romero <[e-mail]>
Organization: RCOM Communications Software
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,es,de-DE,fr-FR
MIME-Version: 1.0
To: Kurt Zeilenga <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
References: <[e-mail]> <[e-mail]>		<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.37
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>

Hi Kurt:

CRAM-MD5  is designed to prevent disclosure of authentication
data, and not privacy, delivery authentication, or identify
confirmation.
Most of those other issues can be handled by robust end to end
encryption of  E-Mail content. In most cases identity falsification
occurs due to the E-Mail originator being sloppy about protecting
his or her authentication data rather than a CRAM-MD5 failure.

Best Regards,

Paul R.


Kurt Zeilenga wrote:

> On Feb 26, 2009, at 9:28 PM, Paul Romero wrote:
>
> > I have observed that a lot of servers still use CRAM-MD5 which
> > seems OK when the E-Mail program is not used within a browser.
>
> If you don't mind your SMTP/IMAP/POP/... sessions being eavesdropped
> upon or highjacked.
>
> -- Kurt

--
Paul Romero

RCOM Communications Software

Phone/Fax: [phone]
E-Mail: [e-mail]




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 n1RD0iYu050283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 06:00:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1RD0iF5050282; Fri, 27 Feb 2009 06:00:44 -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 [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1RD0WRa050272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 27 Feb 2009 06:00:43 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id n1RD0RHo052460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Feb 2009 13:00:28 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Paul Romero <[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 v930.3)
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Date: Fri, 27 Feb 2009 05:00:27 -0800
References: <[e-mail]> <[e-mail]>		<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
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 Feb 26, 2009, at 9:28 PM, Paul Romero wrote:

> I have observed that a lot of servers still use CRAM-MD5 which
> seems OK when the E-Mail program is not used within a browser.

If you don't mind your SMTP/IMAP/POP/... sessions being eavesdropped  
upon or highjacked.

-- 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 n1R9wBX0038680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Feb 2009 02:58:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1R9wBSG038679; Fri, 27 Feb 2009 02:58:11 -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 n1R9vx0w038655 for <[e-mail]>; Fri, 27 Feb 2009 02:58:10 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.242.119] (92.40.242.119.sub.mbb.three.co.uk [92.40.242.119])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 27 Feb 2009 09:57:58 +0000
Message-ID: <[e-mail]>
Date: Fri, 27 Feb 2009 09:57:45 +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: Paul Romero <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Paul Romero wrote:

>Hi Jeffry:
>
>I will look at RFC 3365 as you suggested.  However,
>I have observed that a lot of servers still use CRAM-MD5 which
>seems OK when the E-Mail program is not used within a browser.
>Disturbingly, especially in the case of an MS Outlook server,
>sometimes PLAIN and LOGIN authentication without TLS are
>the only choices offered.  (i.e. Bit off topic.)  It isn't obvious
>to me why PLAIN over TLS would be more prevalent than
>CRAM-MD5.
>  
>
Hi Paul,
A mandatory-to-implement authentication mechanism doesn't necessarily 
mean that it is prevalent, but it means that the specified 
authentication mechanism is considered to be more secure/better/etc. by 
the IETF community.

Alexey

P.S. I can rant about MS Outlook compliance with various email related 
standards, but I should probably do this off-list.

>Best Regards,
>
>Paul R.
>
>
>Jeffrey Hutzelman wrote:
>  
>
>>--On Thursday, February 26, 2009 08:13:48 AM -0800 Paul Romero
>><[e-mail]> wrote:
>>    
>>
>>>Hi Simon:
>>>
>>>I would like your interpretation of the section of  RFC 4954
>>>which applies to  using  PLAIN authentication over TLS.
>>>Section 4 contains the following statement on this subject:
>>>
>>>"To ensure interoperability, client and server implementations of
>>>this extension MUST implement the [PLAIN] SASL mechanism
>>>running over [TLS] [SMTP-TLS]."
>>>
>>>Does this mean that supporting both TLS and PLAIN is
>>>an absolute requirement for a client, or that a client can
>>>only use PLAIN authentication if it supports and agrees
>>>to using TLS ?
>>>      
>>>
>>It means what it says.  If a client implements RFC4954, it must be able to
>>do PLAIN over TLS; otherwise, it is nonconformant.  This requirement is
>>necessary to insure interoperability, because some servers will not support
>>anything other than PLAIN over TLS.
>>    
>>
>>>I suppose a lot of people have asked this question.
>>>      
>>>
>>Not on the ietf-sasl list, they haven't.  Of course, the question is really
>>only indirectly related to SASL, so it's possible people have asked on
>>other lists.
>>    
>>
>>>It is of
>>>concern to me because small SMTP clients in embedded
>>>environments often do not have sufficient resources to support TLS.
>>>A strict interpretation of the section 4 language means support
>>>for TLS is mandatory for all clients.
>>>      
>>>
>>That is the correct interpretation; TLS is mandatory for all
>>implementattions of RFC4954.  See section 7 of RFC3365 for a partial
>>explanation of why.
>>
>>It should be noted that nothing said by Simon, myself, or anyone else on
>>this list should be interpreted as an official position of the IETF.  The
>>positions of the IETF and its working groups are determined by rough
>>consensus as determined by the appropriate leadership.  RFC4954 and RFC3365
>>are examples of products of IETF consensus.
>>
>>-- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
>>   Carnegie Mellon University - Pittsburgh, PA
>>    
>>



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 n1R5RQ4L023505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 22:27:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1R5RQk5023504; Thu, 26 Feb 2009 22:27:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.lmi.net (shell.lmi.net [66.117.140.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1R5RF0E023495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 26 Feb 2009 22:27:26 -0700 (MST) (envelope-from [e-mail])
Received: from rcom-software.com (ftp.rcom-software.com [75.101.82.95]) by shell.lmi.net (8.14.1/8.14.1) with ESMTP id n1R5RAwf081548; Thu, 26 Feb 2009 21:27:10 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 26 Feb 2009 21:28:30 -0800
From: Paul Romero <[e-mail]>
Organization: RCOM Communications Software
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,es,de-DE,fr-FR
MIME-Version: 1.0
To: Jeffrey Hutzelman <[e-mail]>
CC: [e-mail]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
References: <[e-mail]> <[e-mail]>		<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.37
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>

Hi Jeffry:

I will look at RFC 3365 as you suggested.  However,
I have observed that a lot of servers still use CRAM-MD5 which
seems OK when the E-Mail program is not used within a browser.
Disturbingly, especially in the case of an MS Outlook server,
sometimes PLAIN and LOGIN authentication without TLS are
the only choices offered.  (i.e. Bit off topic.)  It isn't obvious
to me why PLAIN over TLS would be more prevalent than
CRAM-MD5.

Best Regards,

Paul R.


Jeffrey Hutzelman wrote:

> --On Thursday, February 26, 2009 08:13:48 AM -0800 Paul Romero
> <[e-mail]> wrote:
>
> >
> > Hi Simon:
> >
> > I would like your interpretation of the section of  RFC 4954
> > which applies to  using  PLAIN authentication over TLS.
> > Section 4 contains the following statement on this subject:
> >
> > "To ensure interoperability, client and server implementations of
> > this extension MUST implement the [PLAIN] SASL mechanism
> > running over [TLS] [SMTP-TLS]."
> >
> > Does this mean that supporting both TLS and PLAIN is
> > an absolute requirement for a client, or that a client can
> > only use PLAIN authentication if it supports and agrees
> > to using TLS ?
>
> It means what it says.  If a client implements RFC4954, it must be able to
> do PLAIN over TLS; otherwise, it is nonconformant.  This requirement is
> necessary to insure interoperability, because some servers will not support
> anything other than PLAIN over TLS.
>
> > I suppose a lot of people have asked this question.
>
> Not on the ietf-sasl list, they haven't.  Of course, the question is really
> only indirectly related to SASL, so it's possible people have asked on
> other lists.
>
> > It is of
> > concern to me because small SMTP clients in embedded
> > environments often do not have sufficient resources to support TLS.
> > A strict interpretation of the section 4 language means support
> > for TLS is mandatory for all clients.
>
> That is the correct interpretation; TLS is mandatory for all
> implementattions of RFC4954.  See section 7 of RFC3365 for a partial
> explanation of why.
>
> It should be noted that nothing said by Simon, myself, or anyone else on
> this list should be interpreted as an official position of the IETF.  The
> positions of the IETF and its working groups are determined by rough
> consensus as determined by the appropriate leadership.  RFC4954 and RFC3365
> are examples of products of IETF consensus.
>
> -- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
>    Carnegie Mellon University - Pittsburgh, PA

--
Paul Romero

RCOM Communications Software

Phone/Fax: [phone]
E-Mail: [e-mail]




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 n1R4TPr4021072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 21:29:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1R4TPsq021071; Thu, 26 Feb 2009 21:29:25 -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 n1R4TCPX021062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 26 Feb 2009 21:29:23 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-236-105.pools.spcsdns.net (72-61-139-84.pools.spcsdns.net [72.61.139.84]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1R4T8sA016655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 23:29:09 -0500 (EST)
Date: Thu, 26 Feb 2009 23:29:07 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Paul Romero <[e-mail]>, Simon Josefsson <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[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
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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 Thursday, February 26, 2009 08:13:48 AM -0800 Paul Romero 
<[e-mail]> wrote:

>
> Hi Simon:
>
> I would like your interpretation of the section of  RFC 4954
> which applies to  using  PLAIN authentication over TLS.
> Section 4 contains the following statement on this subject:
>
> "To ensure interoperability, client and server implementations of
> this extension MUST implement the [PLAIN] SASL mechanism
> running over [TLS] [SMTP-TLS]."
>
> Does this mean that supporting both TLS and PLAIN is
> an absolute requirement for a client, or that a client can
> only use PLAIN authentication if it supports and agrees
> to using TLS ?

It means what it says.  If a client implements RFC4954, it must be able to 
do PLAIN over TLS; otherwise, it is nonconformant.  This requirement is 
necessary to insure interoperability, because some servers will not support 
anything other than PLAIN over TLS.


> I suppose a lot of people have asked this question.

Not on the ietf-sasl list, they haven't.  Of course, the question is really 
only indirectly related to SASL, so it's possible people have asked on 
other lists.


> It is of
> concern to me because small SMTP clients in embedded
> environments often do not have sufficient resources to support TLS.
> A strict interpretation of the section 4 language means support
> for TLS is mandatory for all clients.

That is the correct interpretation; TLS is mandatory for all 
implementattions of RFC4954.  See section 7 of RFC3365 for a partial 
explanation of why.




It should be noted that nothing said by Simon, myself, or anyone else on 
this list should be interpreted as an official position of the IETF.  The 
positions of the IETF and its working groups are determined by rough 
consensus as determined by the appropriate leadership.  RFC4954 and RFC3365 
are examples of products of IETF consensus.


-- Jeffrey T. Hutzelman (N3NHS) <[e-mail]>
   Carnegie Mellon University - Pittsburgh, PA



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 n1QJmhDa092167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 12:48:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1QJmhF6092166; Thu, 26 Feb 2009 12:48:43 -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 n1QJmTB3092147 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 26 Feb 2009 12:48:40 -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 n1QJmT69025255 for <[e-mail]>; Thu, 26 Feb 2009 19:48: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 n1QJmSeM000974 for <[e-mail]>; Thu, 26 Feb 2009 12:48:28 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1QJW0ri009093; Thu, 26 Feb 2009 13:32:00 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1QJVvjD009092; Thu, 26 Feb 2009 13:31:57 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 26 Feb 2009 13:31:57 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Thu, Feb 26, 2009 at 10:54:54AM -0800, [e-mail] wrote:
> Asuuming the GS2 headers here are constants, I think this is simple ehough.

The GS2 headers contain:

a) max buffer size, which is not really a constant, but which isn't all
   that variable in practice;

   (for apps that want channel binding this will be a constant as it's
   not relevant if no sec layers are used)

b) security layer proposals, which also are not really constants, and
   also not that variable in practice;

   (for apps that want channel binding this will be a constant, and for
   apps that don't want channel binding this will be a constant in the
   cases of SCRAM if we decide to provide only integrity protection)

c) the mechanism name;

   (for apps that want channel binding this is not a constant, but it
   does come from listing the server's SASL mechs; for apps that don't
   want channel binding this is as good as constant)

c) a small handful of boolean flags:

    - one is a constant in the SCRAM case (the RFC2743 compression flag);
    - one is true if channel binding is in being done;
    - and a flag to indicate server acceptance/rejection of client
      maxbuf and sec layers proposals.

   (for apps that keep to fixed maxbuf/channel binding proposals these
   are as good as constant)

These aren't all exactly constants, but the variability is minimal.

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 n1QIwIFJ089021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 11:58:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1QIwIgP089020; Thu, 26 Feb 2009 11:58:18 -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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1QIw65R089003 for <[e-mail]>; Thu, 26 Feb 2009 11:58:16 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 26 Feb 2009 10:58:02 -0800 (PST)
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, 26 Feb 2009 10:57:52 -0800 (PST)
Date: Thu, 26 Feb 2009 10:54:54 -0800 (PST)
From: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-reply-to: "Your message dated Mon, 23 Feb 2009 15:21:33 -0600" <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail], Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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 Mon, Feb 23, 2009 at 11:45:29AM -0800, [e-mail] wrote:
> > > I find the inability to use the same authentication
> > > infrastructures in a variety of application protocols to be a serious
> > > issue.  This is not about retiring SASL!  This is about getting
> > > commonality of mechanisms.
> >
> > That's your goal. My goal is different: I want a mechanism that's capable of
> > actually deploying into the application clients and servers I'm interested in,
> > including but not limited to assorted email protocols, XMPP, and calendar. All
> > the commonality of mechanism in the universe doesn't mean squat to me if nobody
> > bothers to add support for either one, which is the likely outcome unless we
> > hammer every last bit of unnecessary obscurity and complexity out of this.

> We (Sam, Jeff and I) know now how to get rid of this last bit of
> obscurity.

> > > > I can tell this issue of wire-compatibility is important to you, but
> >
> > > Actually, it's not at all.  There is no wire compatibility in this case.
> > > That was never the point.  The point is re-use.
> >
> > Not to be catty or anything, but use has to preceed re-use.

> Please be catty, but do at least review the following :)

> This is what SCRAM would look like in the new GS2, and with pretty
> names.

> Here the client wants channel binding, no security layers, and max
> buffer == 8192:

>       C: Request authentication exchange (not a GS2 message, but a SASL one)
>       S: Empty Challenge
>       C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
> 	 ---------------  ----------------------------
> 	 GS2 header           SCRAM message
>          ^^^^^^^^^^ ^ ^ ^ ----------------------------
> 	 max buffer | | |
> 	            | | |
> 	            | | channel binding is being used
> 	            | |
> 	            | SCRAM, as a standard GSS mech, would have that
> 		    | RFC2743 header, thus we compress it as "T" here
> 		    |
> 		    sec layer requested (none)

> 	 The channel bindings data will have been:

> 	    SCRAM-CB 0x00002000 n T T <actual TLS channel binding>

>       S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
>          ^ -------------------------------------------
> 	 |          SCRAM message
> 	 |
> 	 GS2 header indicating that the server accepts the client's max
> 	 buffer size and requested sec layers

>       C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
>       S: v=WxPv/siO5l+qxN4
>       C: Empty message
>       S: Outcome of authentication exchange (not a GS2 message, ...)

> Here's the same exchange, but with the server rejecting the client's
> proposed max buffer:

>       C: Request authentication exchange (not a GS2 message, but a SASL one)
>       S: Empty Challenge
>       C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
> 	 ---------------  ----------------------------
> 	 GS2 header           SCRAM message
>          ^^^^^^^^^^ ^ ^ ^ ----------------------------
> 	 max buffer | | |
> 	            | | |
> 	            | | channel binding is being used
> 	            | |
> 	            | SCRAM, as a standard GSS mech, would have that
> 		    | RFC2743 header, thus we compress it as "T" here
> 		    |
> 		    sec layer requested (none)

> 	 The channel bindings data will have been:

> 	    SCRAM-CB 0x00002000 n T T <actual TLS channel binding>

>       S: R 0x00001000 ni;
>          ^ ^^^^^^^^^^ ^^^
> 	 |     |      |
> 	 |     |      T server supports none and integrity for sec layers
> 	 |     |
> 	 | The server supports 4096 as the largest max buffer
> 	 |
> 	 Client proposal rejected

>       C: 0x00001000 n T T n=Chris Newman,r=ClientNonce

> 	 Same as above, but with the smaller max buffer.

> 	 The channel bindings data will have been:

> 	    SCRAM-CB 0x00001000 ni; 0x00001000 n T T <actual TLS channel binding>
> 	             ^^^^^^^^^^^^^^
> 		     |
> 		     The server's proposal gets added to the channel
> 		     bindings to provide integrity protection for it.

>       S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
>       C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
>       S: v=WxPv/siO5l+qxN4
>       C: Empty message
>       S: Outcome of authentication exchange (not a GS2 message, ...)

> All the hash values and channel bindings data are fake.  The SCRAM
> messages are taken straight from Chris' draft.

> Comments?

Asuuming the GS2 headers here are constants, I think this is simple ehough.

				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 n1QGChCA077086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 09:12:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1QGChrI077085; Thu, 26 Feb 2009 09:12:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.lmi.net (shell.lmi.net [66.117.140.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1QGCVtt077053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 26 Feb 2009 09:12:42 -0700 (MST) (envelope-from [e-mail])
Received: from rcom-software.com (ftp.rcom-software.com [75.101.82.95]) by shell.lmi.net (8.14.1/8.14.1) with ESMTP id n1QGCUPU046272; Thu, 26 Feb 2009 08:12:30 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 26 Feb 2009 08:13:48 -0800
From: Paul Romero <[e-mail]>
Organization: RCOM Communications Software
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,es,de-DE,fr-FR
MIME-Version: 1.0
To: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: TLS Requirement in SMTP RFC4954 and SASL
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.37
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>

Hi Simon:

I would like your interpretation of the section of  RFC 4954
which applies to  using  PLAIN authentication over TLS.
Section 4 contains the following statement on this subject:

"To ensure interoperability, client and server implementations of
this extension MUST implement the [PLAIN] SASL mechanism
running over [TLS] [SMTP-TLS]."

Does this mean that supporting both TLS and PLAIN is
an absolute requirement for a client, or that a client can
only use PLAIN authentication if it supports and agrees
to using TLS ?

I suppose a lot of people have asked this question. It is of
concern to me because small SMTP clients in embedded
environments often do not have sufficient resources to support TLS.
A strict interpretation of the section 4 language means support
for TLS is mandatory for all clients.

Best Regards,

Paul R.




Simon Josefsson wrote:

> Paul Romero <[e-mail]> writes:
>
> > Hi Simon:
> >
> > What you wrote is consistent with what I have read
> > in the SASL group E-Mail and postings. I am not
> > sure my question about SASL RFCs was 100% clear.
> > The important part of the question is, what percentage
> > of SASL implementations follow the latest version of
> > the SASL RFC ?   Is that what you understood from
> > my previous E-Mail ?
>
> Hi again.  Ah, I didn't catch that: however the latest RFCs are
> backwards compatible, and I am not aware of any change introduced that
> would generate problems.  So I believe these new RFCs are just to update
> the specification documentation itself, not to change anything in
> implementation.
>
> Regards,
> Simon
>
> > Best Regards,
> >
> > Paul  R.
> >
> > Simon Josefsson wrote:
> >
> >> Paul Romero <[e-mail]> writes:
> >>
> >> > Hi Simon:
> >> >
> >> > I  would like your observations about the use of  DIGEST-MD5
> >> > in the commercial world within the SASL context.  Do you
> >> > think it is frequently used and gaining greater acceptance ?
> >> > Also, what percentage of commercial implementations do
> >> > you think conform the RFC 4616 and 4954 SASL ?
> >>
> >> Hi Paul.  PLAIN (RFC 4616) and smtp-auth (RFC 4954) are widely
> >> implemented and deployed, and I believe all major implementations are
> >> conforming to the standard.
> >>
> >> For DIGEST-MD5, the situation is a bit different though.  DIGEST-MD5 is
> >> not as widely implemented as for example CRAM-MD5 (see RFC 2195) and
> >> interop testing of various DIGEST-MD5 implementations have demonstrated
> >> many problems.  Briefly, the security layer features of DIGEST-MD5 do
> >> not interoperate well among existing implementations.  Thus, you would
> >> typically only use it for the authentication step.  DIGEST-MD5 is
> >> relatively common, though, but I believe practically all implementations
> >> that support DIGEST-MD5 also supports CRAM-MD5 unless there a local
> >> administrator has made a policy decision to disable CRAM-MD5.
> >>
> >> Within the SASL WG in the IETF, we are trying to develop a replacement
> >> for DIGEST-MD5 called SCRAM.  The protocol is not stable yet, and there
> >> are no implementations of it, however I do think it is the future.
> >>
> >> I would recommend you to support PLAIN and CRAM-MD5 and don't spend too
> >> much time on DIGEST-MD5 if you can avoid it.
> >>
> >> Hope this helps,
> >> /Simon
> >
> > --
> > Paul Romero
> >
> > RCOM Communications Software
> >
> > Phone/Fax: [phone]
> > E-Mail: [e-mail]

--
Paul Romero

RCOM Communications Software

Phone/Fax: [phone]
E-Mail: [e-mail]




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 n1OH8ffp079967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 10:08:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1OH8fvZ079966; Tue, 24 Feb 2009 10:08:41 -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 n1OH8UL6079955 for <[e-mail]>; Tue, 24 Feb 2009 10:08:41 -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 567954AC68; Tue, 24 Feb 2009 18:08:29 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1235495308-22117-1/6/29 (3 recipients); Tue, 24 Feb 2009 18:08:28 +0100
Message-Id: <[e-mail]>
Date: Tue, 24 Feb 2009 18:09:53 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Paul Romero <[e-mail]>
Subject: Re: SASL Requirements Specification
Cc: [e-mail]
References: <[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>

Paul Romero writes:
> Is there some document similar to a PICS  that states SASL conformance 
> requirements ?

No single document, I'm afraid.

> I am particularly interested in this question relative RFCs  4954 and
> 4422 which cover using SASL for SMTP authentication.

4954 says what you MUST do and what you also SHOULD do. When you read 
the MUSTs, you'll also come to MUSTs and SHOULDs in other documents, 
notably 4422 and 4616. Which documets are relevant is clear from the 
MUSTs and SHOULDs in 4954; they're all listed in the section 'normative 
references' in 4954.

  When you've finished recursively adding MUSTs and SHOULDs from the 
other documents, you have the conformance requirements.

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 n1OGToHt077627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 09:29:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1OGToJG077626; Tue, 24 Feb 2009 09:29:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.lmi.net (shell.lmi.net [66.117.140.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1OGTd1U077609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 24 Feb 2009 09:29:49 -0700 (MST) (envelope-from [e-mail])
Received: from rcom-software.com (ftp.rcom-software.com [75.101.82.95]) by shell.lmi.net (8.14.1/8.14.1) with ESMTP id n1OGTbdi032559 for <[e-mail]>; Tue, 24 Feb 2009 08:29:37 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 24 Feb 2009 08:30:56 -0800
From: Paul Romero <[e-mail]>
Organization: RCOM Communications Software
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,es,de-DE,fr-FR
MIME-Version: 1.0
To: [e-mail]
Subject: SASL Requirements Specification
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.37
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>

Dear Group:

Is there some document similar to a PICS  that states
SASL conformance requirements ?  I am particularly
interested in this question relative RFCs  4954 and
4422 which cover using SASL for SMTP authentication.

Best Regards,

Paul Romero

--
Paul Romero

RCOM Communications Software

Phone/Fax: [phone]
E-Mail: [e-mail]




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 n1O26vk7031130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 19:06:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1O26vwr031129; Mon, 23 Feb 2009 19:06:57 -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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1O26j8H031112 for <[e-mail]>; Mon, 23 Feb 2009 19:06:56 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 23 Feb 2009 18:06:24 -0800 (PST)
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]; Mon, 23 Feb 2009 12:03:29 -0800 (PST)
Date: Mon, 23 Feb 2009 11:45:29 -0800 (PST)
From: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-reply-to: "Your message dated Mon, 23 Feb 2009 10:51:24 -0600" <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[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 Mon, Feb 23, 2009 at 10:40:05AM +0000, Dave Cridland wrote:
> > On Sat Feb 21 18:40:22 2009, Nicolas Williams wrote:
> > >extended GSS-API mechanism inquiry becomes widely implemented.
> > >Pretty
> > >SASL mechnames would just be icing on the cake though -- the other
> > >issues are far more important.
> >
> > Then you misunderstand the reality of the situation - I'm afraid that
> > whatever you might wish for, the reality is that the name is
> > crucially important. I'm finding myself struggling to see where the
> > incomprehension stems from.

> I don't see why the particular bits that appear on the wire as
> "mechanism name" are all that important -- that's what I was talking
> about.

> The *actual* mechanism name -- the name by which we know it in
> conversations, e-mails, documentation, ... -- that matters greatly.

> Does that resolve the conflict?  Or did you really mean that the bits
> that appear on the wire as "mechanism name" are greatly important?

'm afraid Dave really does mean that. And while I'm not quite as adamant about
the urgency of being able to advertise comprehensible mechanism on the wire as
Dave is, I do agree that having incomprehensible ones is a barrier to
deployment. And given how unlikely this is to deploy at this late date so
matter what we do, such barriers need to be removed if at all possible.

> > I strongly suspect that if a bespoke implementor finds GS2 before
> > they find SCRAM they'll give up at that point irregardless of how
> > simple the mechanism is. I'm not even convinced that most developers,

> Which is why we want a SCRAM-as-GS2-but0described-as-pure-SASL document.

> > faced with a mechanism name consisting of random characters, will
> > even look up a specification. To get these developers to read and
> > implement the specification, the mechanism needs to be not only
> > simple, but seen to be simple.

> But I don't think they'll be faced with "a mechanism name consisting of
> random characters" (besides the fact that they are only random-looking
> :)

They will in the case of someone examining the output of what mechanisms a
particular server offers.

> The fact is that when customers request support for SCRAM they won't
> say "I want you to support GS2A-EVBXI4ERUDP3Z7AT" or anything of the
> sort.

Of course not. But this is entirely beside the point.

> > Even if they get as far as reading the spec, most client authors will
> > probably decide to do what I did, which is to interrogate the hash
> > library as to what hashes I have available and look for mechanism
> > names. This approach to hash agility is handy, in as much as with
> > GS2, it won't require me to perform a preimage attack on the
> > mechanism name, however it has the disadvantage that with GS2's
> > cryptographically secure names [I'm told I shouldn't call them
> > encrypted] I have to implement a DER encoder (at least for OIDs).

> Not really.  I've seen DER-encoded OIDs hardcoded in C source plenty.

> > And, perhaps more tellingly, I cannot be bothered to do this -

> You don't have to be.  The name is effectively constant and so can just
> be hardcoded, just as you'd hardcode the name if it weren't
> random-looking.

> > Which means hash agility is actually harmed, and yes, it really is

> This is NOT about hash agility.

> > On a more positive note, I'm firmly convinced that wire
> > interoperability between GSS-API and "native" SASL mechanisms is so
> > unimportant as to be a waste of time to persue. I never did
> > understand the argument that we should somehow retire SASL to
> > increase wire compatibility between protocols which are
> > wire-incompatible.

> Do you support or have you deployed GSS-API and SASL based applications?
> I do/have.

I've supported and deployed multiple SASL-based applications. I have attempted
to do GSS-API stuff on a couple of occasions but have never been successful.

> I find the inability to use the same authentication
> infrastructures in a variety of application protocols to be a serious
> issue.  This is not about retiring SASL!  This is about getting
> commonality of mechanisms.

That's your goal. My goal is different: I want a mechanism that's capable of
actually deploying into the application clients and servers I'm interested in,
including but not limited to assorted email protocols, XMPP, and calendar. All
the commonality of mechanism in the universe doesn't mean squat to me if nobody
bothers to add support for either one, which is the likely outcome unless we
hammer every last bit of unnecessary obscurity and complexity out of this.

> > I can tell this issue of wire-compatibility is important to you, but

> Actually, it's not at all.  There is no wire compatibility in this case.
> That was never the point.  The point is re-use.

Not to be catty or anything, but use has to preceed re-use.

				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 n1NMJWSP019606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 15:19:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NMJWTY019605; Mon, 23 Feb 2009 15:19: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-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 n1NMJLFe019594 for <[e-mail]>; Mon, 23 Feb 2009 15:19:31 -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 n1NMJKT2024193 for <[e-mail]>; Mon, 23 Feb 2009 22:19:20 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 n1NMJKo2023043 for <[e-mail]>; Mon, 23 Feb 2009 15:19:20 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1NM2qit005922; Mon, 23 Feb 2009 16:02:52 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1NM2qAh005921; Mon, 23 Feb 2009 16:02:52 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Feb 2009 16:02:52 -0600
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Mon, Feb 23, 2009 at 03:02:17PM -0600, Nicolas Williams wrote:
> I spoke to Sam about this today and we have an agreement on what to do
> to make pretty SASL mechs on the wire possible.
> 
> I'll write it up later, but the point is: the name issue will go away
> too.
> 
> So please review the example message exchanges (I should have put those
> first) in the new design that I sent today.

Here's what we'll do about GS2 mech names:

1) Create a registry of GSS-API mechanism OID -> pretty SASL mech name
   mappings.

2) Add an abstract API to the GSS-API: GSS_SASL_name() that outputs the
   SASL name of a GSS-API mechanism.

3) GS2 will use the pretty name on wire for all GSS-API mechanisms
   except for mechanisms that have no registered SASL name.

   For mechanisms that have no registered SASL name GS2 will use a
   hash-based name.  This means it's important for GSS-API mechanisms to
   be born with a SASL name.

   (Also, what we call "composed mechanisms" may not have pretty SASL
   names ever, but that's really not an issue as no such mechanisms
   exist now and anyways they are mechanically composed, thus they
   arguably don't need pretty names or, in any case, might end up having
   very long composed pretty names.)

I think that should settle the last major issue.

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 n1NM3pi1018473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 15:03:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NM3pqv018472; Mon, 23 Feb 2009 15:03:51 -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 n1NM3puf018466 for <[e-mail]>; Mon, 23 Feb 2009 15:03:51 -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 n1NM3pDO026543 for <[e-mail]>; Mon, 23 Feb 2009 22:03:51 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 n1NM3oGE040623 for <[e-mail]>; Mon, 23 Feb 2009 15:03:50 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1NLsrvj005914 for <[e-mail]>; Mon, 23 Feb 2009 15:54:53 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1NLsrof005913 for [e-mail]; Mon, 23 Feb 2009 15:54:53 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Feb 2009 15:54:53 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Mon, Feb 23, 2009 at 12:50:55PM -0600, Nicolas Williams wrote:
>  - ABNF

The ABNF I posted contained one bug: the server-sec-layers rule results
in an ambiguity.  This is trivial to fix.

Also, the name rule will now be exactly what it is in RFC4422:

    sasl-mech    = 1*20mech-char
    mech-char    = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
    ...

and a punctuation char (say, ';') can be used to separate the sasl-mech
name from other protocol elements.

The updated ABNF, then:

; Basic types
; OCTET, ... are core ABNF types; their definitions are excluded here
;
gss-sec-token = *OCTET		; a GSS-API security context token
buf-size = 4OCTET		; SASL buffer size
sec-layer =  "n"	; no sec layer
sec-layer =/ "i"	; integrity sec layer
sec-layer =/ "c"	; confidentiality (+ integrity) sec layer
sasl-gs2-mech-name =  sasl-mech "-CB" ";"
sasl-gs2-mech-name =/ sasl-mech "-NOCB" ";"

client-max-bux = buf-size
server-max-buf = buf-size
client-sec-layer-req = sec-layer
server-sec-layers = 1*3sec-layer ";"	; list of sec layers; this can
					; probably be specified better

; GS2 error message / header for first acceptor GSS sec context token
gs2-server-params = server-max-buf server-sec-layers
gs2-server-first-response =  ( R gs2-server-params )	; server rejects
							; the client's
							; max buffer
							; and/or sec
							; layers reqs
gs2-server-first-response =/ ( A gss-sec-token )	; server accepts
							; the client's
							; max buffer
							; and/or sec
							; layers reqs

; Types for GS2 header for first initiator GSS sec context token

; Compression of RFC2743 initial sec context token header (which has an
; annoying DER length that must be computed; here we elide it so that
; pure SASL implementors can avoid the pain of DER length
; encoding/decoding).
gss-init-token-standard-header-present = T / F
	; If the GSS-API standard init sec context OID header is present
	; then set this to T and remove that header from the initial
	; GSS-API context token, else set this bit to F

; If TLS (or whatever) channel binding is being done the client
; indicates it in the header using a boolean.
channel-bindings-present = T / F

; The actual header, including max buffer, sec layer, and the above two
; types.
gs2-client-first-header =  ( client-max-bux client-sec-layer-req
			      gss-init-token-standard-header-present
			      channel-bindings-present )

; Actual GS2 first client message: the header and the GSS-API initial
; context token (minus the RFC2743 initial context token header).
gs2-client-first-message = ( gs2-client-first-header gss-sec-token )


; The following is the ABNF for the GS2 header prefixed to the GSS-API
; channel binding data.
channel-type = *ALPHA "-"
channel-binding-data = *OCTET
channel-bindings-header = ( sasl-gs2-mech-name [gs2-server-params]
			    gs2-client-first-header )
;
; If the server rejected the client's initial max buffer / sec layer
; requests then the server's parameters are included in the channel-
; bindings-header (see optional bits above).
;
; GSS-API channel binding is *always* used, even when no channel is
; being bound (see optional bits below).
;
; Finally, note that this rule is not referenced above.  That's because
; it's only used to construct the channel bindings that will be fed to
; the mechanism and does not appear in the message exchanges show above,
; not directly.
gs2-channel-binding-data = channel-bindings-header
			   [(channel-type channel-binding-data)]



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 n1NLca4E016845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 14:38:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NLcalg016844; Mon, 23 Feb 2009 14:38:36 -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 n1NLcDb3016821 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 23 Feb 2009 14:38:25 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1NLc1ER029083 for <[e-mail]>; Mon, 23 Feb 2009 21:38:13 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 n1NLc0Oh020129 for <[e-mail]>; Mon, 23 Feb 2009 14:38:00 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1NLLXUO005885; Mon, 23 Feb 2009 15:21:33 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1NLLXdc005884; Mon, 23 Feb 2009 15:21:33 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Feb 2009 15:21:33 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Mon, Feb 23, 2009 at 11:45:29AM -0800, [e-mail] wrote:
> > I find the inability to use the same authentication
> > infrastructures in a variety of application protocols to be a serious
> > issue.  This is not about retiring SASL!  This is about getting
> > commonality of mechanisms.
> 
> That's your goal. My goal is different: I want a mechanism that's capable of
> actually deploying into the application clients and servers I'm interested in,
> including but not limited to assorted email protocols, XMPP, and calendar. All
> the commonality of mechanism in the universe doesn't mean squat to me if nobody
> bothers to add support for either one, which is the likely outcome unless we
> hammer every last bit of unnecessary obscurity and complexity out of this.

We (Sam, Jeff and I) know now how to get rid of this last bit of
obscurity.

> > > I can tell this issue of wire-compatibility is important to you, but
> 
> > Actually, it's not at all.  There is no wire compatibility in this case.
> > That was never the point.  The point is re-use.
> 
> Not to be catty or anything, but use has to preceed re-use.

Please be catty, but do at least review the following :)

This is what SCRAM would look like in the new GS2, and with pretty
names.

Here the client wants channel binding, no security layers, and max
buffer == 8192:

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
	 ---------------  ----------------------------
	 GS2 header           SCRAM message
         ^^^^^^^^^^ ^ ^ ^ ----------------------------
	 max buffer | | | 
	            | | |
	            | | channel binding is being used
	            | |
	            | SCRAM, as a standard GSS mech, would have that
		    | RFC2743 header, thus we compress it as "T" here
		    |
		    sec layer requested (none)

	 The channel bindings data will have been:

	    SCRAM-CB 0x00002000 n T T <actual TLS channel binding>

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         ^ -------------------------------------------
	 |          SCRAM message
	 |
	 GS2 header indicating that the server accepts the client's max
	 buffer size and requested sec layers

      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

Here's the same exchange, but with the server rejecting the client's
proposed max buffer:

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
	 ---------------  ----------------------------
	 GS2 header           SCRAM message
         ^^^^^^^^^^ ^ ^ ^ ----------------------------
	 max buffer | | | 
	            | | |
	            | | channel binding is being used
	            | |
	            | SCRAM, as a standard GSS mech, would have that
		    | RFC2743 header, thus we compress it as "T" here
		    |
		    sec layer requested (none)

	 The channel bindings data will have been:

	    SCRAM-CB 0x00002000 n T T <actual TLS channel binding>

      S: R 0x00001000 ni;
         ^ ^^^^^^^^^^ ^^^
	 |     |      |
	 |     |      T server supports none and integrity for sec layers
	 |     |
	 | The server supports 4096 as the largest max buffer
	 |
	 Client proposal rejected

      C: 0x00001000 n T T n=Chris Newman,r=ClientNonce

	 Same as above, but with the smaller max buffer.

	 The channel bindings data will have been:

	    SCRAM-CB 0x00001000 ni; 0x00001000 n T T <actual TLS channel binding>
	             ^^^^^^^^^^^^^^
		     |
		     The server's proposal gets added to the channel
		     bindings to provide integrity protection for it.

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

All the hash values and channel bindings data are fake.  The SCRAM
messages are taken straight from Chris' draft.

Comments?

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 n1NLIwtB015606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 14:18:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NLIw3a015605; Mon, 23 Feb 2009 14:18:58 -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 n1NLIkiX015582 for <[e-mail]>; Mon, 23 Feb 2009 14:18:57 -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 n1NLIkDF006644 for <[e-mail]>; Mon, 23 Feb 2009 21:18:46 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 n1NLIjgC004832 for <[e-mail]>; Mon, 23 Feb 2009 14:18:45 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1NL2IGc005859; Mon, 23 Feb 2009 15:02:18 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1NL2H1P005858; Mon, 23 Feb 2009 15:02:17 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Feb 2009 15:02:17 -0600
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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>

I spoke to Sam about this today and we have an agreement on what to do
to make pretty SASL mechs on the wire possible.

I'll write it up later, but the point is: the name issue will go away
too.

So please review the example message exchanges (I should have put those
first) in the new design that I sent today.



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 n1NJuaIt010929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 12:56:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NJuaE3010928; Mon, 23 Feb 2009 12:56:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NJuMg2010904 for <[e-mail]>; Mon, 23 Feb 2009 12:56:34 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <SaL=[e-mail]>; Mon, 23 Feb 2009 19:57:18 +0000
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 23 Feb 2009 19:56:15 +0000
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
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 Feb 23 16:51:24 2009, Nicolas Williams wrote:
> On Mon, Feb 23, 2009 at 10:40:05AM +0000, Dave Cridland wrote:
> > On Sat Feb 21 18:40:22 2009, Nicolas Williams wrote:
> > >extended GSS-API mechanism inquiry becomes widely implemented.
> > >Pretty
> > >SASL mechnames would just be icing on the cake though -- the  
> other
> > >issues are far more important.
> >
> > Then you misunderstand the reality of the situation - I'm afraid  
> that
> > whatever you might wish for, the reality is that the name is
> > crucially important. I'm finding myself struggling to see where  
> the
> > incomprehension stems from.
> 
> I don't see why the particular bits that appear on the wire as
> "mechanism name" are all that important -- that's what I was talking
> about.
> 
> The *actual* mechanism name -- the name by which we know it in
> conversations, e-mails, documentation, ... -- that matters greatly.
> 
> Does that resolve the conflict?

No, because the developers that represent the great bulk of potential  
implementors won't be a party to the conversations and e-mails, and  
will only get as far as the documentation if sufficiently interested.

>   Or did you really mean that the bits
> that appear on the wire as "mechanism name" are greatly important?
> 
> 
... and these "bits on the wire" are going to be their first contact,  
and they'll form a first impression very quickly based on that.  
They'll even base their decision to find and read the specification  
based purely on the name, and how often they see it.

> The fact is that when customers request support for SCRAM they won't
> say "I want you to support GS2A-EVBXI4ERUDP3Z7AT" or anything of the
> sort.
> 
> 
No, of course not. They'll say (as they do say to us, sometimes) "We  
have a policy that no passwords may be stored in the clear, how can  
you help us?". Typically, whatever solution we suggest will receive  
an immediate question of "How many of the common clients implement  
that?". As such, I'd like our answer to the former to involve SCRAM,  
and our answer to the latter to be "Lots".

I couldn't give a rodent's hindquarters how elegant the integration  
is with GSS-API, I only care whether I can get the right answers to  
my customers. I appreciate this is possibly a little pragmatic, and  
pragmatism is looked down upon in security circles.

> You don't have to be.  The name is effectively constant and so can  
> just
> be hardcoded, just as you'd hardcode the name if it weren't
> random-looking.
> 
> 
But I *haven't* hardcoded the names, yet I *have* implemented  
SCRAM-HMAC-* with multiple hashes, so your argument is dashed to  
peices on the hard rocks of reality. (I've hardcoded "SCRAM-HMAC-",  
"MD5", and "SHA-" - the 1 or bitlength is appended based on what I  
find in the Python hashlib).

> > Which means hash agility is actually harmed, and yes, it really is
> 
> This is NOT about hash agility.
> 
> 
Nope. But I think there's an impact there.


> > On a more positive note, I'm firmly convinced that wire
> > interoperability between GSS-API and "native" SASL mechanisms is  
> so
> > unimportant as to be a waste of time to persue. I never did
> > understand the argument that we should somehow retire SASL to
> > increase wire compatibility between protocols which are
> > wire-incompatible.
> 
> Do you support or have you deployed GSS-API and SASL based  
> applications?

I've implemented SASL libraries, and bespoke SASL code. Yes, I'm  
probably biased toward SASL, but I have at least supported and  
deployed multiple different flavours of plaintext auth, and the fact  
they differ in syntax doesn't bother me a jot. 
I've also deployed multi-protocol services for relatively large ISPs  
with common authentication infrastructures over a variety of  
protocols - none of them based on GSS-API, mind.


> I do/have.  I find the inability to use the same authentication
> infrastructures in a variety of application protocols to be a  
> serious
> issue.

Right! *This* is the serious problem. The inability of SASL to have  
any mechanism besides the piss-poor PLAIN which can be used with  
something similar to /etc/shadow is a real pain. The fact that we  
currently give our customers a choice of "Security on the server or  
the wire, pick one" appalls me. (Okay, we do offer X.509 Strong Auth,  
too, but in terms of passwords...)

SCRAM solves this, and I have a burning need to ensure this solution  
is available ubiquitously - otherwise I'd have not bothered entering  
this debate at all.

>   This is not about retiring SASL!  This is about getting
> commonality of mechanisms.
> 
> 
And I'm telling you it's unimportant - it's the commonality in the  
authentication infrastructure that's important. Yes, a commonality of  
mechanisms does imply a commonality of infrastructure, and it's quite  
an elegant solution if it can be made to work, but I don't think it's  
sufficiently transparent to be made to work as effectively, and I  
think the SASL mechanism name alone is sufficient to cause serious  
deployment shortfall.


> > I can tell this issue of wire-compatibility is important to you,  
> but
> 
> Actually, it's not at all.  There is no wire compatibility in this  
> case.
> That was never the point.  The point is re-use.

Great. So get the reuse where it's important, and worry about it  
there.

I get the distinct impression that a "true" GSS-API mechanism based  
around the same algorithm as SCRAM-HMAC-* is possible, and would look  
somewhat different (ie, it might well have security layers, and  
sundry other GSS-API-ish properties that fit better there). I'd have  
thought that this would surely offer the best of both worlds.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



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 n1NIxs0T007795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 11:59:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NIxsCb007794; Mon, 23 Feb 2009 11:59:54 -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 n1NIxr9J007788 for <[e-mail]>; Mon, 23 Feb 2009 11:59:53 -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 n1NIxrEO011373 for <[e-mail]>; Mon, 23 Feb 2009 18:59:53 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 n1NIxr7X026708 for <[e-mail]>; Mon, 23 Feb 2009 11:59:53 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1NIouN4005817 for <[e-mail]>; Mon, 23 Feb 2009 12:50:56 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1NIotm9005816 for [e-mail]; Mon, 23 Feb 2009 12:50:55 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Feb 2009 12:50:55 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[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 Fri, Feb 20, 2009 at 06:06:47PM -0600, Nicolas Williams wrote:
> The goal: to make GS2 simple enough that SCRAM-as-GS2 can look as simple
> as an incremental update to DIGEST-MD5, whether described as a pure SASL
> mechanism or as a GSS-API mechanism used via GS2.
> 
> The following are the constraints we must meet as Jeff and I understand
> them right now:

Below is the new design, which needs to be read in conjunction with the
text I sent on Friday describing what the new goals and requirements
are.

This is a long post because it contains:

 - ABNF
 - Two sets of examples: one by reference to the ABNF, one with what an
   actual SCRAM-GS2 exchange would look like
 - Plenty of descriptive text

Fee free to read this out of order.

The new, simplified GS2 would be more or less as follows:

 - Only GSS security context tokens are used in the SASL authentication
   exchanges.

 - GSS-API channel binding is used to provide integrity protection for
   all plaintext bits on the wire added by GS2, as well as to provide
   channel binding support for SASL.

 - GS2 bits on the wire are used for:

    - SASL max buffer negotiation
    - SASL security layer negotiation
    - channel binding negotiation

Very little needs to be changed in draft-newman-auth-scram-09.txt to
make it a pure SASL description of SCRAM-as-new-GS2.

First let's look at generic SASL/GS2 authentication message exchanges.
Here I'll be making reference to the ABNF for GS2.  Further below I'll
actually give some examples of what SCRAM-GS2 will look like based on
draft-newman-auth-scram-09.txt, with actual/made up values instead of
ABNF rule names.

Terminology note: "initiator" and "acceptor" are GSS-API terms roughly
corresponding to SASL's "client" and "server".  Below when I use the GSS
terminology I am referring to the GSS-API mechanism wrapped by GS2, and
when I use the SASL terminology I am referring to the SASL application
and/or GS2.

Case 1: The GSS-API mech initiator has the last token and client max
	buffer/sec layer requests are acceptable to the server.

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: gs2-client-first-message	; see ABNF below
      S: gs2-server-first-response	; "   "    "
      C: gss-sec-token			; "   "    "
      S: gss-sec-token
      ...
      C: gss-sec-token
      S: Outcome of authentication exchange (not a GS2 message, ...)

Case 2: The GSS-API mech acceptor has the last token and client max
	buffer/sec layer requests are acceptable to the server.

      C: Request authentication exchange (not a GS2 message, ...)
      S: Empty Challenge
      C: gs2-client-first-message
      S: gs2-server-first-response
      C: gss-sec-token
      S: gss-sec-token
      ...
      C: Empty Response
      S: Outcome of authentication exchange (not a GS2 message, ...)

Case 3: The client's max buffer/sec layer requests are not acceptable to
	the server.  This case has an extra round-trip.

      C: Request authentication exchange
      S: Empty Challenge
      C: gs2-client-first-message
      S: gs2-server-first-response
      C: gs2-server-params gs2-client-first-message
      S: gss-sec-token
      C: gss-sec-token
      ...
      <rest as in case #1 or case #2>

The ABNF for the GS2 messages is as follows.

; Basic types
; OCTET, ... are core ABNF types; their definitions are excluded here
;
gss-sec-token = *OCTET		; a GSS-API security context token
buf-size = 4OCTET		; SASL buffer size
sec-layer =  "n"	; no sec layer
sec-layer =/ "i"	; integrity sec layer
sec-layer =/ "c"	; confidentiality (+ integrity) sec layer
sasl-gs2-mech-name =  "GS2A-" 16BASE32
sasl-gs2-mech-name =/ "GS2B-" 16BASE32
	; See notes below on why there are two GS2 SASL mech name forms.
	; Also, see separate thread about how we might get pretty
	; mechanism names, instead of ugly names that have base32
	; encoded hash of GSS-API mechanism OIDs...

client-max-bux = buf-size
server-max-buf = buf-size
client-sec-layer-req = sec-layer
server-sec-layers = 1*3sec-layer	; list of sec layers; this can
					; probably be specified better

; GS2 error message / header for first acceptor GSS sec context token
gs2-server-params = server-max-buf server-sec-layers
gs2-server-first-response =  ( R gs2-server-params )	; server rejects
							; the client's
							; max buffer
							; and/or sec
							; layers reqs
gs2-server-first-response =/ ( A gss-sec-token )	; server accepts
							; the client's
							; max buffer
							; and/or sec
							; layers reqs

; Types for GS2 header for first initiator GSS sec context token

; Compression of RFC2743 initial sec context token header (which has an
; annoying DER length that must be computed; here we elide it so that
; pure SASL implementors can avoid the pain of DER length
; encoding/decoding).
gss-init-token-standard-header-present = T / F
	; If the GSS-API standard init sec context OID header is present
	; then set this to T and remove that header from the initial
	; GSS-API context token, else set this bit to F

; If TLS (or whatever) channel binding is being done the client
; indicates it in the header using a boolean.
channel-bindings-present = T / F

; The actual header, including max buffer, sec layer, and the above two
; types.
gs2-client-first-header =  ( client-max-bux client-sec-layer-req
			      gss-init-token-standard-header-present
			      channel-bindings-present )

; Actual GS2 first client message: the header and the GSS-API initial
; context token (minus the RFC2743 initial context token header).
gs2-client-first-message = ( gs2-client-first-header gss-sec-token )


; The following is the ABNF for the GS2 header prefixed to the GSS-API
; channel binding data.
channel-type = *ALPHA "-"
channel-binding-data = *OCTET
channel-bindings-header = ( sasl-gs2-mech-name [gs2-server-params]
			    gs2-client-first-header )
;
; If the server rejected the client's initial max buffer / sec layer
; requests then the server's parameters are included in the channel-
; bindings-header (see optional bits above).
;
; GSS-API channel binding is *always* used, even when no channel is
; being bound (see optional bits below).
;
; Finally, note that this rule is not referenced above.  That's because
; it's only used to construct the channel bindings that will be fed to
; the mechanism and does not appear in the message exchanges show above,
; not directly.
gs2-channel-binding-data = channel-bindings-header
			   [(channel-type channel-binding-data)]

There will be two GS2 SASL mechnames for every GSS-API mechanism: one to
indicate that the server supports channel binding (e.g., to TLS), the
other one to indicate that the server does not.  This, combined with the
channel-bindings-present boolean in the gs2-client-first-header and in
the channel-bindings-header lets GS2 prevent downgrade attacks in the
case that a) TLS (or whatever) is in use and b) the server can't do
channel binding (e.g., because either or both of its TLS or SASL
libraries don't support it).

The mechname form GS2A-<OID-hash> will indicate channel binding support,
and the form GS2B-<OID-hash> will indicate the opposite.  The server
will advertise one or the other, BUT NEVER BOTH.

When a server advertises GS2A-<OID-hash> and the client uses
GS2B-<OID-hash> then there's a downgrade attack and the server MUST
reject authentication.  The server detects this because the mechname
chosen by the client will be bound into the GS2 exchange using the
GSS-API channel bindings -- *all* GS2 plaintext, including the mechname,
is integrity protected by including said plaintext in the channel-
bindings-header.

As you can see the new GS2 would consist of small headers used in just a
few places, with no length encodings anywhere.  And the new GS2 still
manages to be round-trip optimized in the common case.

GS2 security layers are *exactly* the same as specified in RFC2222.

This means that SCRAM should specify how to do GSS wrap tokens with
integrity protection.  This is very simple for SCRAM: the token will
consist of a sequence number, a MAC (of the wrapped data and sequence
#), and the wrapped data (no length need be encoded by SCRAM itself,
though there is a length encoding in the GS2 layer since there is one in
RFC2222's "GSSAPI" mechanism).  I'm assuming separate session keys for
each direction, otherwise there should be a direction flag in the token
as well.

A confidentiality sec layer could also be done for SCRAM, but I don't
think that's worthwhile.

A formal description of the new GS2 wouldn't be much longer than the
above text with RFC2119 terminology and references thrown in.

And now the examples with actual values.

Case 4: Same as case #1 above.  Additionally the client wants 8192 as
        its max buffer size, channel binding, and no security layers.

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
	 ---------------  ----------------------------
	 GS2 header           SCRAM message
         ^^^^^^^^^^ ^ ^ ^ ----------------------------
	 max buffer | | | 
	            | | |
	            | | channel binding is being used
	            | |
	            | SCRAM, as a standard GSS mech, would have that
		    | RFC2743 header, thus we compress it as "T" here
		    |
		    sec layer (none)

	 The channel bindings data will have been:

	    GS2A-SCRAMhash 0x00002000 n T T <actual TLS channel binding>

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         ^ -------------------------------------------
	 |          SCRAM message
	 |
	 GS2 header indicating that the server accepts the client's max
	 buffer size and requested sec layers
      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

Case 5: Same as case #4, but with the server rejecting the client's max
	buffer proposal.

      C: Request authentication exchange (not a GS2 message, but a SASL one)
      S: Empty Challenge
      C: 0x00002000 n T T n=Chris Newman,r=ClientNonce
	 ---------------  ----------------------------
	 GS2 header           SCRAM message
         ^^^^^^^^^^ ^ ^ ^ ----------------------------
	 max buffer | | | 
	            | | |
	            | | channel binding is being used
	            | |
	            | SCRAM, as a standard GSS mech, would have that
		    | RFC2743 header, thus we compress it as "T" here
		    |
		    sec layer (none)

	 The channel bindings data will have been:

	    GS2A-SCRAMhash 0x00002000 n T T <actual TLS channel binding>

      S: R 0x00001000 ni
         ^ ^^^^^^^^^^ ^^
	 |     |      |
	 |     |      T server supports none and integrity for sec layers
	 |     |
	 | The server supports 4096 as the largest max buffer
	 |
	 Client proposal rejected

      C: 0x00001000 n T T n=Chris Newman,r=ClientNonce

	 The channel bindings data will have been:

	    GS2A-SCRAMhash 0x00001000 ni 0x00001000 n T T <actual TLS channel binding>

      S: A r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4
      C: Empty message
      S: Outcome of authentication exchange (not a GS2 message, ...)

All the hash values and channel bindings data are fake.

Comments?

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 n1NHb3Pc002913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 10:37:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NHb3w9002912; Mon, 23 Feb 2009 10:37:03 -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 n1NHaqCP002894 for <[e-mail]>; Mon, 23 Feb 2009 10:37:02 -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 n1NHapU3029753 for <[e-mail]>; Mon, 23 Feb 2009 17:36:51 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 n1NHapJM063999 for <[e-mail]>; Mon, 23 Feb 2009 10:36:51 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1NHKNXT005741; Mon, 23 Feb 2009 11:20:23 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1NHKK7l005740; Mon, 23 Feb 2009 11:20:20 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Feb 2009 11:20:20 -0600
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Mon, Feb 23, 2009 at 10:51:23AM -0600, Nicolas Williams wrote:
> On Mon, Feb 23, 2009 at 10:40:05AM +0000, Dave Cridland wrote:
> > On Sat Feb 21 18:40:22 2009, Nicolas Williams wrote:
> > >extended GSS-API mechanism inquiry becomes widely implemented.   
> > >Pretty
> > >SASL mechnames would just be icing on the cake though -- the other
> > >issues are far more important.

Also, to be clear, the point I was making in the above quote is this:
of all the problems we need to surmount in making GS2 and SCRAM-as-GS2
acceptable, the form of the mechanism names that appears on the wire was
the least of them, thus, solving that problem after solving all the
others was "icing on the cake."

And, to be clear, I don't oppose Jeff's proposal as to how to get pretty
SASL mechnames on the wire, but I recall that Sam did once oppose it,
and I explained what the reasons were as I recalled them.

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 n1NH8DtV001114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 10: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 n1NH8Dbf001113; Mon, 23 Feb 2009 10: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 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 n1NH7wR3001095 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 23 Feb 2009 10:08:10 -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 n1NH7ua3013344 for <[e-mail]>; Mon, 23 Feb 2009 17:07:58 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 n1NH7tFa038647 for <[e-mail]>; Mon, 23 Feb 2009 10:07:55 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1NGpRPh005685; Mon, 23 Feb 2009 10:51:27 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1NGpOX5005684; Mon, 23 Feb 2009 10:51:24 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Feb 2009 10:51:24 -0600
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Mon, Feb 23, 2009 at 10:40:05AM +0000, Dave Cridland wrote:
> On Sat Feb 21 18:40:22 2009, Nicolas Williams wrote:
> >extended GSS-API mechanism inquiry becomes widely implemented.   
> >Pretty
> >SASL mechnames would just be icing on the cake though -- the other
> >issues are far more important.
> 
> Then you misunderstand the reality of the situation - I'm afraid that  
> whatever you might wish for, the reality is that the name is  
> crucially important. I'm finding myself struggling to see where the  
> incomprehension stems from.

I don't see why the particular bits that appear on the wire as
"mechanism name" are all that important -- that's what I was talking
about.

The *actual* mechanism name -- the name by which we know it in
conversations, e-mails, documentation, ... -- that matters greatly.

Does that resolve the conflict?  Or did you really mean that the bits
that appear on the wire as "mechanism name" are greatly important?

> I strongly suspect that if a bespoke implementor finds GS2 before  
> they find SCRAM they'll give up at that point irregardless of how  
> simple the mechanism is. I'm not even convinced that most developers,  

Which is why we want a SCRAM-as-GS2-but0described-as-pure-SASL document.

> faced with a mechanism name consisting of random characters, will  
> even look up a specification. To get these developers to read and  
> implement the specification, the mechanism needs to be not only  
> simple, but seen to be simple.

But I don't think they'll be faced with "a mechanism name consisting of
random characters" (besides the fact that they are only random-looking
:)

The fact is that when customers request support for SCRAM they won't
say "I want you to support GS2A-EVBXI4ERUDP3Z7AT" or anything of the
sort.

> Even if they get as far as reading the spec, most client authors will  
> probably decide to do what I did, which is to interrogate the hash  
> library as to what hashes I have available and look for mechanism  
> names. This approach to hash agility is handy, in as much as with  
> GS2, it won't require me to perform a preimage attack on the  
> mechanism name, however it has the disadvantage that with GS2's  
> cryptographically secure names [I'm told I shouldn't call them  
> encrypted] I have to implement a DER encoder (at least for OIDs).

Not really.  I've seen DER-encoded OIDs hardcoded in C source plenty.

> And, perhaps more tellingly, I cannot be bothered to do this -  

You don't have to be.  The name is effectively constant and so can just
be hardcoded, just as you'd hardcode the name if it weren't
random-looking.

> Which means hash agility is actually harmed, and yes, it really is  

This is NOT about hash agility.

> On a more positive note, I'm firmly convinced that wire  
> interoperability between GSS-API and "native" SASL mechanisms is so  
> unimportant as to be a waste of time to persue. I never did  
> understand the argument that we should somehow retire SASL to  
> increase wire compatibility between protocols which are  
> wire-incompatible.

Do you support or have you deployed GSS-API and SASL based applications?
I do/have.  I find the inability to use the same authentication
infrastructures in a variety of application protocols to be a serious
issue.  This is not about retiring SASL!  This is about getting
commonality of mechanisms.

> I can tell this issue of wire-compatibility is important to you, but  

Actually, it's not at all.  There is no wire compatibility in this case.
That was never the point.  The point is re-use.

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 n1NGxv5G000601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 09:59:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NGxvYP000600; Mon, 23 Feb 2009 09:59:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NGxk1V000587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 23 Feb 2009 09:59:56 -0700 (MST) (envelope-from [e-mail])
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id F220753B8AC2 for <[e-mail]>; Mon, 23 Feb 2009 08:59:45 -0800 (PST)
Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id DBF2228098 for <[e-mail]>; Mon, 23 Feb 2009 08:59:45 -0800 (PST)
X-AuditID: 1180711d-a401cbb000000ff0-ca-49a2d601fa94
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay13.apple.com (Apple SCV relay) with ESMTP id BD00A28092 for <[e-mail]>; Mon, 23 Feb 2009 08:59:45 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; delsp=yes; charset=us-ascii; format=flowed
Received: from nutcracker.apple.com (nutcracker.apple.com [17.202.45.101]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 23 Feb 2009 08:59:45 -0800 (PST)
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Message-id: <[e-mail]>
In-reply-to: <[e-mail]>
Cc: SASL WG <[e-mail]>, [e-mail]
Date: Mon, 23 Feb 2009 08:59:44 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.1044)
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>

>>>     This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF   
>>> and
>>>     with dkLen == output length of HMAC() == output length of H().
>>
>> If it is PBKDF2 is should say so and not be fuzzy.
>
> If somebody can verify that independently, then I will change the  
> text ;-).

Just write that it uses PBKDF2 with HMAC and output keysize = sizeof(H 
(), put the description in an non normative appendix.

It looks like PBKDF2 to me.

>> When I see Hi(str, salt), I get confused every time, i is an input
>> parameter, but is still part of the function name ?
>
> Yea. It Should be <Something>(str, salt, i)
>
>> Why is ClientProof  the result of ClientKey XOR ClientSignature ?
>> That  does that accomplish ?
>
> The server is able to calculate ClientSignature. From the ClientProof
> and that it can recover ClientKey, apply hash function once to get
> StoredKey and can verify that the client really knows the StoredKey
> (i.e. it knows the password).

If the client can calculate ClientSignature = HMAC(H(H(PBKDF2 
(password, salt, i))), AuthMessage),
I would not be worried about it not knowing the password, why do you  
need the extra step ?

Chris, this was in -00 of the draft, why did you do it this way ?

Right now the client and server key differences is:

ClientKey = H(SaltedPassword)
ServerKey = HMAC(SaltedPassword, salt)

Why are the derived by two different methods ? (why not XKey = HMAC 
(SaltedKey, "X key")

Love



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 n1NB4LOL076981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 04:04:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NB4Lad076979; Mon, 23 Feb 2009 04:04:21 -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 n1NB48ea076964 for <[e-mail]>; Mon, 23 Feb 2009 04:04:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.118] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 23 Feb 2009 11:04:05 +0000
Message-ID: <[e-mail]>
Date: Mon, 23 Feb 2009 11:03:55 +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: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable
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>

Love H=F6rnquist =C5strand wrote:

> 22 feb 2009 kl. 02:47 skrev Alexey Melnikov:
>
>> This contains some minor fixes discovered by Dave Cridland and myself
>> while implementing the spec (actually 2 separate implementations, =20
>> one in
>> C and one in Python), in particular an error in ABNF production name
>
> The draft says:
>
> >      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF  and
> >      with dkLen =3D=3D output length of HMAC() =3D=3D output length of H=
().
>
> If it is PBKDF2 is should say so and not be fuzzy.

If somebody can verify that independently, then I will change the text ;-).

> When I see Hi(str, salt), I get confused every time, i is an input =20
> parameter, but is still part of the function name ?

Yea. It Should be <Something>(str, salt, i)

> Why is ClientProof  the result of ClientKey XOR ClientSignature ?=20
> That  does that accomplish ?

The server is able to calculate ClientSignature. From the ClientProof=20
and that it can recover ClientKey, apply hash function once to get=20
StoredKey and can verify that the client really knows the StoredKey=20
(i.e. it knows the password).



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 n1NAeWxB075676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 03:40:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1NAeWqX075675; Mon, 23 Feb 2009 03:40:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1NAeK9Q075657 for <[e-mail]>; Mon, 23 Feb 2009 03:40:31 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Mon, 23 Feb 2009 10:41:07 +0000
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 23 Feb 2009 10:40:05 +0000
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
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 Sat Feb 21 18:40:22 2009, Nicolas Williams wrote:
> extended GSS-API mechanism inquiry becomes widely implemented.   
> Pretty
> SASL mechnames would just be icing on the cake though -- the other
> issues are far more important.

Then you misunderstand the reality of the situation - I'm afraid that  
whatever you might wish for, the reality is that the name is  
crucially important. I'm finding myself struggling to see where the  
incomprehension stems from.

Let's review how this mechanism, under whatever form it finally turns  
out, gets implemented and deployed.

1) Step one is that it gets designed and specified.

2) Step two is that the SASL libraries, or GSS-API libraries, include  
support for it. In particular, this means libraries like Cyrus SASL,  
et al. These implementations are done by people familiar with, and  
probably involved with, the specification.

3) Step three, optional, is that a protocol or environment uses it as  
a MTI. (In SCRAM's case, the candidate is XMPP, but we won't do this  
if we're concerned about complexity).

4) Step four is when server implementations which aren't using SASL  
libraries start to include support. In the XMPP world, many servers  
use Cyrus SASL or some such, and that accounts for some widely  
deployed servers like ejabberd, but not (as I recall) all of the  
popular ones. The email world tends to be more conservative, and many  
server-side SASL implementations are bespoke at least in my  
experience.

5) Step five, which occurs concurrently, is where client deployment  
starts. Most client authors will not include support for SCRAM until  
it's widely deployed in servers, and many client authors - especially  
in the relatively scattered email world - will first hear of the  
mechanism by seeing it advertised. Essentially all client SASL  
implementations are bespoke - although in principle Cyrus SASL et al  
support a client mode, for whatever reason it seems very unpopular to  
use it.

I strongly suspect that if a bespoke implementor finds GS2 before  
they find SCRAM they'll give up at that point irregardless of how  
simple the mechanism is. I'm not even convinced that most developers,  
faced with a mechanism name consisting of random characters, will  
even look up a specification. To get these developers to read and  
implement the specification, the mechanism needs to be not only  
simple, but seen to be simple.

To a certain extent, then, those that read the specification aren't  
really the audience you need to convince - nor, indeed, is anyone  
here.

Even if they get as far as reading the spec, most client authors will  
probably decide to do what I did, which is to interrogate the hash  
library as to what hashes I have available and look for mechanism  
names. This approach to hash agility is handy, in as much as with  
GS2, it won't require me to perform a preimage attack on the  
mechanism name, however it has the disadvantage that with GS2's  
cryptographically secure names [I'm told I shouldn't call them  
encrypted] I have to implement a DER encoder (at least for OIDs).

Oddly enough, for an XMPP/IMAP kind of guy, I actually know how to do  
this, and even know enough to think it might be the same as BER,  
hence I've even written it before, but it's relatively niche  
knowledge in the XMPP and email worlds.

And, perhaps more tellingly, I cannot be bothered to do this -  
SCRAM-HMAC-* took me about three or four hours, including a rough  
stab at channel binding. From prior experience, writing sufficient  
code to make this a GS2-<<MD5(SCRAM-HASH)>> will take me an  
equivalent amount of time. And no, in my implementation, supporting  
GSS-API isn't really an option.

Which means hash agility is actually harmed, and yes, it really is  
all in a name - Will S notwithstanding, a SCRAM by any other name  
turns out not to smell as sweet.

On a more positive note, I'm firmly convinced that wire  
interoperability between GSS-API and "native" SASL mechanisms is so  
unimportant as to be a waste of time to persue. I never did  
understand the argument that we should somehow retire SASL to  
increase wire compatibility between protocols which are  
wire-incompatible.

The important compatibility factor is allowing multiple mechanisms  
and authentication systems to share a common backend.

In our (Isode's) case, for example, we have two situations we care  
about:

a) Passwords are stored in the DSA in the clear. Mechanisms like  
DIGEST-MD5 and CRAM-MD5 are available to clients.

b) Passwords are stored in the DSA hashed. Only PLAIN (and X.509  
Simple Auth, XEP-0078, IMAP LOGIN, etc) are supported.

This is a Hobson's choice - wire security or DSA security. SCRAM  
allows this to be extended with a third choice - if we can choose the  
hashing mechanism in the DSA (which we often can), we can support  
SCRAM, too.

You all, hopefully, knew all this, but I get the impression that  
somewhere along the line, this has been forgotten.

If we did much with GSS-API (we don't), then we'd care about  
supporting some secure-ish password based mechanism in GSS-API, too,  
using the same attributes in the DSA. I doubt we'd bemoan the sad  
lack of wire compatibility, for the same reason we don't care about  
the sad lack of wire compatibility between X.509 Simple Auth and  
XEP-0078 - we just check a password. Writing the additional code to  
support all these PLAIN-a-likes isn't a huge amount of effort, and  
there's one of these *per protocol*, not just per authentication  
system.

This backend compatibility is great - nay, awesome - for us, and,  
too, for most service operators out there. To my mind, wire  
compatibility is - and I quote - "NEAT to have, not need to have".

I can tell this issue of wire-compatibility is important to you, but  
I don't believe for a moment it's important to your customers, it's  
certainly not important to ours, and I think it's going to actively  
damage deployment.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



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 n1N0xeub048909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2009 17:59:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1N0xeIa048908; Sun, 22 Feb 2009 17:59:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1N0xTeQ048897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 22 Feb 2009 17:59:40 -0700 (MST) (envelope-from [e-mail])
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 072CA53A6A50 for <[e-mail]>; Sun, 22 Feb 2009 16:59:29 -0800 (PST)
Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Brightmail Gateway) with ESMTP id E4F3F2807D for <[e-mail]>; Sun, 22 Feb 2009 16:59:28 -0800 (PST)
X-AuditID: 11807130-a4889bb000000fcd-12-49a1f4f0a984
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with ESMTP id C8BAB28086 for <[e-mail]>; Sun, 22 Feb 2009 16:59:28 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; delsp=yes; charset=us-ascii; format=flowed
Received: from nutcracker.apple.com (nutcracker.apple.com [17.202.45.101]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Sun, 22 Feb 2009 16:59:28 -0800 (PST)
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Message-id: <[e-mail]>
In-reply-to: <[e-mail]>
Cc: SASL WG <[e-mail]>
Date: Sun, 22 Feb 2009 16:59:27 -0800
References: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.1044)
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>

22 feb 2009 kl. 02:47 skrev Alexey Melnikov:

> This contains some minor fixes discovered by Dave Cridland and myself
> while implementing the spec (actually 2 separate implementations,  
> one in
> C and one in Python), in particular an error in ABNF production name


The draft says:

 >      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF  
and
 >      with dkLen == output length of HMAC() == output length of H().

If it is PBKDF2 is should say so and not be fuzzy.

When I see Hi(str, salt), I get confused every time, i is an input  
parameter, but is still part of the function name ?

Why is ClientProof  the result of ClientKey XOR ClientSignature ? That  
does that accomplish ?

Love




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 n1MLW7Xm039564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2009 14:32:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1MLW7RT039563; Sun, 22 Feb 2009 14:32:07 -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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1MLVuuq039546 for <[e-mail]>; Sun, 22 Feb 2009 14:32:06 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1MLVtwN001881 for <[e-mail]>; Sun, 22 Feb 2009 21:31:55 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 n1MLVs2r042187 for <[e-mail]>; Sun, 22 Feb 2009 14:31:55 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1MLFQDJ005000; Sun, 22 Feb 2009 15:15:26 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1MLFNVf004999; Sun, 22 Feb 2009 15:15:23 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sun, 22 Feb 2009 15:15:23 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: SASL WG <[e-mail]>, Dave Cridland <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Sun, Feb 22, 2009 at 09:30:37PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >In our case OIDs are just constant, opaque octet strings -- there's no 
> >need to parse them, no need to do any conversions whatever.
> 
> AFAICT they don't suffer from the evils that have given OIDs a bad name 
> either. But that won't stop people from getting a bad impression if 
> they see the word OID.
> 
> Dave: Would you please repeat your usual story about buzzwords, first 
> impressions and the likelihood of reading the RFC at all, etc, etc?

It's all not relevant: SCRAM-as-new-GS2 will not be using OIDs at all
(except when used as a pure GSS-API mechanism outside the world of SASL,
and then only because RFC2743 requires it).



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 n1MKTTcJ036992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2009 13:29:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1MKTT63036991; Sun, 22 Feb 2009 13:29:29 -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 n1MKTH9J036980 for <[e-mail]>; Sun, 22 Feb 2009 13:29:28 -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 54AF94AC46; Sun, 22 Feb 2009 21:29:16 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1235334555-22117-1/6/15 (3 recipients); Sun, 22 Feb 2009 21:29:15 +0100
Message-Id: <[e-mail]>
Date: Sun, 22 Feb 2009 21:30:37 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: SASL WG <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Cc: Nicolas Williams <[e-mail]>, Dave Cridland <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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>

Nicolas Williams writes:
> In our case OIDs are just constant, opaque octet strings -- there's no 
> need to parse them, no need to do any conversions whatever.

AFAICT they don't suffer from the evils that have given OIDs a bad name 
either. But that won't stop people from getting a bad impression if 
they see the word OID.

Dave: Would you please repeat your usual story about buzzwords, first 
impressions and the likelihood of reading the RFC at all, etc, etc?

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 n1MAm4lX011826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Feb 2009 03:48:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1MAm46g011825; Sun, 22 Feb 2009 03:48:04 -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 n1MAlqoV011809 for <[e-mail]>; Sun, 22 Feb 2009 03:48:03 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.126] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 22 Feb 2009 10:47:50 +0000
Message-ID: <[e-mail]>
Date: Sun, 22 Feb 2009 10:47:30 +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
MIME-Version: 1.0
To: SASL WG <[e-mail]>
Subject: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
Content-Type: multipart/mixed; boundary="------------000504070106020507050202"
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>

--------------000504070106020507050202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This contains some minor fixes discovered by Dave Cridland and myself 
while implementing the spec (actually 2 separate implementations, one in 
C and one in Python), in particular an error in ABNF production name.


--------------000504070106020507050202
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-10.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-10.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine (Isode M-Box/14.3v2) with LMTP; Sun, 22 Feb 2009 10:45:37 +0000 (GMT)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Sun, 22 Feb 2009 10:45:37 +0000
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D59FE3A6A19;
	Sun, 22 Feb 2009 02:45:02 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0)
	id ADA463A69FB; Sun, 22 Feb 2009 02:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-newman-auth-scram-10.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun, 22 Feb 2009 02:45:01 -0800 (PST)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-10.txt
	Pages           : 18
	Date            : 2009-02-22

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------000504070106020507050202--



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 n1LKWUGx083266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2009 13:32:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1LKWUvg083265; Sat, 21 Feb 2009 13:32:30 -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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1LKWUoM083259 for <[e-mail]>; Sat, 21 Feb 2009 13:32:30 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1LKWTJe016280 for <[e-mail]>; Sat, 21 Feb 2009 20:32:30 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 n1LKWTxF032426 for <[e-mail]>; Sat, 21 Feb 2009 13:32:29 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1LKNX63004391 for <[e-mail]>; Sat, 21 Feb 2009 14:23:33 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1LKNXeq004390 for [e-mail]; Sat, 21 Feb 2009 14:23:33 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 21 Feb 2009 14:23:33 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[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 Fri, Feb 20, 2009 at 06:06:47PM -0600, Nicolas Williams wrote:
> The goal: to make GS2 simple enough that SCRAM-as-GS2 can look as simple
> as an incremental update to DIGEST-MD5, whether described as a pure SASL
> mechanism or as a GSS-API mechanism used via GS2.

Specifically, I think it can just be draft-newman-auth-scram-09.txt, but
executed in the context of the new GS2.  The new GS2 effectively adds a
little header to some SCRAM messages (with no ambiguities, no length
encodings, no base64 encodings of SCRAM messages, nothing fancy) and a
little header to the TLS (or whatever) channel binding data.

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 n1LInc5Q078634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2009 11:49:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1LIncXx078633; Sat, 21 Feb 2009 11:49:38 -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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1LInPpF078623 for <[e-mail]>; Sat, 21 Feb 2009 11:49:36 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1LInPLN028836 for <[e-mail]>; Sat, 21 Feb 2009 18:49:25 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 n1LInPh1054197 for <[e-mail]>; Sat, 21 Feb 2009 11:49:25 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1LIePYG004227; Sat, 21 Feb 2009 12:40:25 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1LIeMJO004226; Sat, 21 Feb 2009 12:40:22 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 21 Feb 2009 12:40:22 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[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 Sat, Feb 21, 2009 at 03:45:16PM +0100, Arnt Gulbrandsen wrote:
> 
> Nicolas Williams writes:
> >The following are the constraints we must meet as Jeff and I 
> >understand them right now:
> 
> Looks good. I'd say SHOULD instead of some of the MUSTs (e.g. OIDs have 
> a bad reputation due to SNMP mistakes, but aren't instantly lethal). 
> Looking forward to seeing the results.

In our case OIDs are just constant, opaque octet strings -- there's no
need to parse them, no need to do any conversions whatever.  Thus they
are mostly harmless (the biggest issue is making sure you don't make a
mistake when entering the constant strings into your source code).

In any case, a pure SASL implementation will not have to deal with OIDs.

The GS2 SASL mechanism names will continue to be based on hashing
GSS-API mechanism OIDs.  Jeff proposes that we have nicer names (e.g.,
"GS2A-SCRAM") and a registry of GSS-API mech OID -> SASL mech name that
can be looked up using extended GSS-API mechanism inquiry functions...

...but as I recall Sam opposes this on the reasonable grounds that since
no implementations of extended GSS-API mechanism inquiry exist this will
mean hardcoding these mappings in source code or configuration.
However, given the small number of standard GSS-API mechanisms (Kerberos
V, and soon SCRAM and PKU2U) I think this should be manageable until
extended GSS-API mechanism inquiry becomes widely implemented.  Pretty
SASL mechnames would just be icing on the cake though -- the other
issues are far more important.

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 n1LEiBnn067089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2009 07:44:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1LEiBKA067088; Sat, 21 Feb 2009 07:44:11 -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 n1LEhx6l067060 for <[e-mail]>; Sat, 21 Feb 2009 07:44:11 -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 417894AC94; Sat, 21 Feb 2009 15:43:58 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1235227437-22117-1/6/7 for [e-mail]; Sat, 21 Feb 2009 15:43:57 +0100
Message-Id: <[e-mail]>
Date: Sat, 21 Feb 2009 15:45:16 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[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>

Nicolas Williams writes:
> The following are the constraints we must meet as Jeff and I 
> understand them right now:

Looks good. I'd say SHOULD instead of some of the MUSTs (e.g. OIDs have 
a bad reputation due to SNMP mistakes, but aren't instantly lethal). 
Looking forward to seeing the results.

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 n1L0FseC031060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2009 17:15:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1L0FsB7031059; Fri, 20 Feb 2009 17:15:54 -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 n1L0Fhw6031051 for <[e-mail]>; Fri, 20 Feb 2009 17:15:54 -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 n1L0Fhir000374 for <[e-mail]>; Sat, 21 Feb 2009 00:15:43 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 n1L0FhFP040245 for <[e-mail]>; Fri, 20 Feb 2009 17:15:43 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1L06l3c003804 for <[e-mail]>; Fri, 20 Feb 2009 18:06:47 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1L06lKU003803 for [e-mail]; Fri, 20 Feb 2009 18:06:47 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 20 Feb 2009 18:06:47 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

Jeff Hutzelman and I spent a few hours re-designing GS2 so it's very
simple AND meets our channel binding constraints as discussed recently
on the list.  I've sent Jeff ABNF and sample possible exchanges; when
Jeff replies I will post the complete design, but not later than Monday
(I just want to make sure the actual description will not have obvious
mistakes).

[I may also send a copy to Simon, Sam and/or Alexey off-list.]

The goal: to make GS2 simple enough that SCRAM-as-GS2 can look as simple
as an incremental update to DIGEST-MD5, whether described as a pure SASL
mechanism or as a GSS-API mechanism used via GS2.

The following are the constraints we must meet as Jeff and I understand
them right now:

a) MUST NOT require any GSS-API changes;
b) MUST NOT require any changes to SASL APIs beyond the obvious and
   optional interface by which applications can pass channel bindings
   data to SASL;
c) MUST NOT include length encodings;
d) MUST NOT include two GSS tokens in one SASL auth message;
e) SCRAM-as-GS2 MUST NOT have that annoying GSS-API initial context
   token header naming the mechanism OID;
f) MUST support secure negotiation of security layers and max buffer
   size;
g) MUST support secure negotiation of channel bindings so that TLS
   libraries that don't support channel bindings APIs can be used;
h) channel binding failure MUST result in authentication failure;
i) MUST be round-trip optimized in the common case, but it's acceptable
   for an extra round-trip to occur when the client's max buffer and/or
   security layers requests are unacceptable to the server.

Not required and therefore abandoned:

 - The old GS2 negotiation of security layers being conditional on
   channel binding outcome.

Brief outline:

 - The new GS2 would use GSS-API channel bindings instead of doing
   channel binding at the GS2 layer.  This allows us to satisfy (c), (d)
   and (f).  No GSS-API per-message tokens would be used in the
   construction of SASL GS2 authentication messages.

 - The new GS2 would use two different SASL mechanism name forms to
   indicate whether the server application supports channel binding.
   Combined with the use of GSS-API channel bindings this allows us to
   satisfy (g).  And combined with GSS-API channel binding semantics
   we satisfy (h).

 - The new GS2 would compress the presence/absence of the GSS-API
   initial context token header into a boolean.  This will allow
   pure-SASL implementators of SCRAM-as-GS2 to not have to know how to
   encode/decode that annoying header.  This way we satisfy (e).

 - The new GS2 would incur an extra round-trip when the client's max
   buffer and/or security layers requests are unacceptable to the
   server, thus meeting (i).  This is needed in our design in order to
   meet all the other requirements, particularly (a), (c) and (d).

 - The new GS2 would require no changes to the GSS-API, thus meeting
   (a).

 - The new GS2 would imply no changes to SASL APIs other than the
   implied and optional need for a way to pass channel binding data to
   SASL, thus meeting (b).

Cheers,

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 n1KAI2bH084268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2009 03:18:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1KAI2Qx084267; Fri, 20 Feb 2009 03:18:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1KAHoBK084251 for <[e-mail]>; Fri, 20 Feb 2009 03:18:01 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Fri, 20 Feb 2009 10:18:36 +0000
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <77521CD8A69FA47CD08FBB83@446E7922C82D299DB29D899F> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 20 Feb 2009 10:17:35 +0000
From: Dave Cridland <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, Chris Newman <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
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 Feb 19 16:02:18 2009, [e-mail] wrote:
> The real risk is that an overly complex mechanism will not deploy,  
> or if it
> does deploy, will fail to interoperate. We're coming to the party  
> very, very
> late with this, and even if we end up with as simple a mechanism as  
> we possibly
> can there's still a significant risk this whole thing is going to  
> go exactly
> nowhere.

I'd go so far as to say that actual complexity isn't as important for  
the purposes of deployment as perceived complexity. This ceased to be  
a technical issue some time ago (although there are minor technical  
issues). This is really just a marketing issue, and one that's  
important to address if we want deployment.

Unfortunately, I suspect most of this boils down to the name.

>> If I understand Nico's proposal on 2/17 correctly, it could  
>> simplify the
>> difference between auth-scram-09 and auth-scram-gs2 to just a blob  
>> at the
>> beginning of the first client message.  If it's possible to do  
>> that, then I
>> would support doing so.
> 
> Frankly, this is what I was expecting to see in the current set of  
> drafts - the
> idea of reducing GS2 to an opaque blob has been mentioned many  
> times in the
> past. What I found instead was a significantly more complex  
> alternative.

I'd question whether the average developer is going to go as far as  
finding and reading the specification if the mechanism name is itself  
encrypted. This might sound flippant, and frankly it's hard not to  
make it sound that way, but it's a serious point - deployment isn't  
only about technical merit.

In any case, the key attraction for many operators isn't going to be  
that GSS-API and SASL share the mechanism, but that PLAIN and SCRAM  
can share a secure authentication database. If there's another  
mechanism, GSS-API based, that also shares this backend database,  
that'll no doubt please people who're offering GSS-API services  
alongside SASL services, but I honestly can't see that having wire  
compatibility is all that important by comparison.

Sure, it's a "nice if you can get it", but it ranks far, far below  
the shared authentication backend, which itself means that  
SCRAM-capable services can be deployed right now.

Right now, operators have to choose between storing plaintext  
passwords or require transmitting them, and when forced to choose,  
they appear to go for the latter. With SCRAM, they can deploy a  
SCRAM-style authentication database right now - it's probably very  
close to what they're already using in /etc/shadow or their  
hashed-passwords DSA - they can use it for PLAIN for existing  
clients, and offer SCRAM, and client developers will see SCRAM  
advertised, and implement it because it's simple enough.

So, my conclusion from this is actually very positive - we can have a  
native SASL SCRAM-HMAC-* family, a backend-compatible GSS-API SCRAM  
family, a document describing how to make PLAIN (and XEP-0078, IMAP  
LOGIN, X.509 Simple Authentication, POP3 USER/PASS, FTP, /bin/login  
etc) authenticate against the same backend, and actually have real  
deployment in services now.

On the other hand, if we choose a solution that appears more complex,  
I'm concerned that the result will be that we never get the momentum.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



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 n1KAHbrr084230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2009 03:17:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1KAHbkE084226; Fri, 20 Feb 2009 03:17:37 -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 n1KAHQK1084207 for <[e-mail]>; Fri, 20 Feb 2009 03:17:36 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.121] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 20 Feb 2009 10:17:24 +0000
Message-ID: <[e-mail]>
Date: Fri, 20 Feb 2009 10:17:02 +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: Arnt Gulbrandsen <[e-mail]>
CC: Chris Newman <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <nQFWqcnDPvVCmU/[e-mail]>
In-Reply-To: <nQFWqcnDPvVCmU/[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>

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> But then I think GSS-API implementors would need to see the other 
>> half of the ABNF...
>
> That's acceptable. Optimising for the common case implies that unusual 
> cases don't have to be optimal.

If you suggesting something like moving the full ABNF to Appendix (and 
keeping the expanded one in the main body of the document), then this 
can be done.




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 n1KA6wgk083260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Feb 2009 03:06:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1KA6wnd083259; Fri, 20 Feb 2009 03:06:58 -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 n1KA6jdP083238 for <[e-mail]>; Fri, 20 Feb 2009 03:06:56 -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 6C2074AC6C; Fri, 20 Feb 2009 11:06:44 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1235124403-22117-1/6/1 (4 recipients); Fri, 20 Feb 2009 11:06:43 +0100
Message-Id: <nQFWqcnDPvVCmU/[e-mail]>
Date: Fri, 20 Feb 2009 11:07:59 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Chris Newman <[e-mail]>, SASL WG <[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>

Alexey Melnikov writes:
> But then I think GSS-API implementors would need to see the other half 
> of the ABNF...

That's acceptable. Optimising for the common case implies that unusual 
cases don't have to be optimal.

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 n1JMInKW047572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 15:18:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1JMInPc047571; Thu, 19 Feb 2009 15:18:49 -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 n1JMIbue047534 for <[e-mail]>; Thu, 19 Feb 2009 15:18:48 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.189] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 19 Feb 2009 22:18:36 +0000
Message-ID: <[e-mail]>
Date: Thu, 19 Feb 2009 22:17:30 +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: Chris Newman <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <77521CD8A69FA47CD08FBB83@446E7922C82D299DB29D899F>
In-Reply-To: <77521CD8A69FA47CD08FBB83@446E7922C82D299DB29D899F>
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>

Chris Newman wrote:

> The present formulation of auth-scram-gs2-00 is significantly more 
> complex than auth-scram-09 (ABNF is roughly twice the size).

I will just quickly comment on this: the ABNF is twice the size in order 
to keep GS2 bits separate from SCRAM bits. I could have expanded it for 
SASL implementors. But then I think GSS-API implementors would need to 
see the other half of the ABNF...



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 n1JH0192029805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 10: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 n1JH01Cm029803; Thu, 19 Feb 2009 10: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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1JGxnQU029742 for <[e-mail]>; Thu, 19 Feb 2009 10:00:01 -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 8ABBF4AC73; Thu, 19 Feb 2009 17:59:48 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1235062788-78475-1/6/13 for [e-mail]; Thu, 19 Feb 2009 17:59:48 +0100
Message-Id: <Rf6jjLDNsJvEvK44vg/[e-mail]>
Date: Thu, 19 Feb 2009 18:01:03 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <77521CD8A69FA47CD08FBB83@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>

[e-mail] writes:
> I'm cautiously on board if it can be simplified to the point of being 
> a fixed prefix "blob" per your description below. Anything short of 
> that is still unacceptable IMO.

I'll cautiously +1 that.

> The real risk is that an overly complex mechanism will not deploy, or 
> if it does deploy, will fail to interoperate. We're coming to the 
> party very, very late with this, and even if we end up with as simple 
> a mechanism as we possibly can there's still a significant risk this 
> whole thing is going to go exactly nowhere.

Amen. And even just adding theoretically harmless things such as a 
binary blob or an OID can be risky if it makes people think "oh, it'll 
be horrid like SNMP" instead of looking closer.

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 n1JGAnaI027126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 09:10:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1JGAnJQ027125; Thu, 19 Feb 2009 09:10:49 -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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1JGAbNP027093 for <[e-mail]>; Thu, 19 Feb 2009 09:10:48 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 19 Feb 2009 08:10:35 -0800 (PST)
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, 19 Feb 2009 08:09:56 -0800 (PST)
Date: Thu, 19 Feb 2009 08:02:18 -0800 (PST)
From: [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-reply-to: "Your message dated Wed, 18 Feb 2009 16:26:19 -0800" <77521CD8A69FA47CD08FBB83@446E7922C82D299DB29D899F>
To: Chris Newman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <77521CD8A69FA47CD08FBB83@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>

> I have evaluated both specifications in detail and reviewed the list
> traffic.

> Brief conclusions:

> Given a choice between these two approaches I oppose auth-scram-gs2-00.txt
> and support auth-scram-09.txt.

> However, I believe the WG should evaluate the proposal Nico made on 2/17.
> The crux of that proposal is to change GS2 to remove support for SASL
> security layers and remove use of the GSS_Wrap function (which adds the
> unnecessary hash operation).  Doing so is likely to simplify auth-scram-gs2
> to the point where I would be comfortable with that approach.

I'm cautiously on board if it can be simplified to the point of being a fixed
prefix "blob" per your description below. Anything short of that is still
unacceptable IMO.

> Technical basis for my position:

> I recognize some benefit from having a GSSAPI implementation of SCRAM
> visible through a GS2 SASL mechanism interoperate with a pure SASL SCRAM
> implementation.  However, if there were separate GSSAPI SCRAM and SASL
> SCRAM mechanisms, I believe implementers would make them interoperate when
> it was important to do so, just as some SASL implementers have supported
> non-standard SASL mechanisms like LOGIN, GSS-SPNEGO, and NTLM.  So I
> consider that benefit to be "modest".

> The present formulation of auth-scram-gs2-00 is significantly more complex
> than auth-scram-09 (ABNF is roughly twice the size).  This additional
> complexity provides no _functionality_ improvements over scram-08 but
> requires additional hash-function computation and verification, extra
> binary encoding, and additional escaping.  The additional hash-function
> computation, in particular, has a non-obvious function and the mechanism
> would appear to work fine in most cases (succeeding with valid password,
> failing with invalid password) if an implementer simply chose not to verify
> the additional hash.  That creates a new opportunity for a security
> vulnerability in auth-scram-gs2 that does not exist in auth-scram.  That's
> over and above the additional security vulnerably risk from the necessarily
> larger code quantity.  So I consider the interop benefit to be outweighed
> by the security risk.

The real risk is that an overly complex mechanism will not deploy, or if it
does deploy, will fail to interoperate. We're coming to the party very, very
late with this, and even if we end up with as simple a mechanism as we possibly
can there's still a significant risk this whole thing is going to go exactly
nowhere.

> Further, I consider the need to have SCRAM supplant CRAM and DIGEST a
> higher priority than making SCRAM compatible with GS2.  The overall
> additional complexity of auth-scram-gs2-00 puts that primary goal in
> significant jeopardy to achieve what I consider a secondary goal.  That
> tradeoff is not acceptable to me.

> If I understand Nico's proposal on 2/17 correctly, it could simplify the
> difference between auth-scram-09 and auth-scram-gs2 to just a blob at the
> beginning of the first client message.  If it's possible to do that, then I
> would support doing so.

Frankly, this is what I was expecting to see in the current set of drafts - the
idea of reducing GS2 to an opaque blob has been mentioned many times in the
past. What I found instead was a significantly more complex alternative.

				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 n1JEogGI022509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 07:50:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1JEogEv022508; Thu, 19 Feb 2009 07:50:42 -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 n1JEoTxM022499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 19 Feb 2009 07:50:41 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.144] (173-101-100-205.pools.spcsdns.net [173.101.100.205]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1JEoNRv002561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 09:50:24 -0500 (EST)
Date: Thu, 19 Feb 2009 09:50:22 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>
cc: Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[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
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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 Thursday, February 19, 2009 12:03:53 PM +0000 Alexey Melnikov 
<[e-mail]> wrote:

> Jeffrey Hutzelman wrote:
>
>> --On Tuesday, February 17, 2009 04:44:16 PM -0600 Nicolas Williams
>> <[e-mail]> wrote:
>>
>>> So what makes GS2 not simple?  The fact that we chose to make the GS2
>>> channel binding semantics different from the GSS-API's: we chose to make
>>> channel binding success/failure affect the negotiation of security
>>> layers.
>>>
>>> If we reconsider that one choice we could simplify GS2 enough that a
>>> single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
>>
>> Personally, I'm fine with saying that channel binding must succeed if
>> the application provided bindings.
>
> What should happen if the other end can't verify them, because it has no
> API for doing that?

The purist in me says "get a better TLS implementation".

The part of me that backports security fixes to OpenSSL 0.9.7 because 
upgrading would be more pain than I have time for recognizes that that is 
probably still impractical.


> So, I am Ok with the following semantics: if a channel bind is provided
> by one end and can be verified by the other end, then any failure to
> verify it causes authentication failure, but if the other end doesn't
> have the ability to verify channel bindings, then ignoring them is fine.

I would be OK with that, too, provided we're talking about the behavior 
depending on whether or not the application passed channel binding 
information down through SASL.  Thus, the question of whether to use 
channel bindings remains with the application, and individual applications 
can either require that channel bindings be used all the time or allow them 
to be skipped under some circumstances.

Unfortunately, this doesn't actually work in both directions.  A GSS-API 
acceptor can decide whether to pass channel binding information down to the 
mechanism, but it must make that decision before it has any way of knowing 
whether the initiator sent any.  If the initiator provides channel bindings 
but the acceptor does not, then the context might be established 
successfully, depending in part on the mechanism and possibly on the 
particular mechanism implementation.  If the acceptor provides channel 
bindings and the initiator does not, context establishment will fail.


What Nico is trying to do is propose that we simplify GS2 significantly by 
declaring that its channel binding failure semantics are exactly the same 
as those of GSS-API.  This allows GS2 channel bindings to be provided using 
those of the underlying GSS-API mechanism, rather than as a separate GSS 
MIC token which, depending on the mechanism, may require an extra round 
trip.  It simplifies things considerably by making GS2 into a much thinner 
wrapper.

I cannot think of any way to provide the semantics you describe (in which 
channel binding must succeed, but only if both ends provide data) for all 
GS2 mechanisms without retaining the complexity Nico is trying to remove. 
However, I think we _can_ provide that behavior for SCRAM, or for any other 
particular GSS-API mechanism, by specifying that the mechanism verifies 
channel bindings only if data is provided by both ends.  Whether we 
_should_ do that is another question entirely.


Excuse me for a moment while I delve a bit deeper into GSS-API specifics...

It seems to me that we could define a mechanism property which indicates 
that the mechanism handles channel bindings as described above, verifying 
them only when provided by both initiator and acceptor.  SCRAM would have 
this feature, and GS2 would be defined to make use of the feature when it 
is available (as determined by extended mechanism inquiry), and implement 
GS2 channel bindings in terms of GSS MIC tokens when it is not.  This would 
have the effect of keeping GS2+SCRAM simple while allowing GS2+RFC4121 to 
have the desired channel binding semantics even though Kerberos does not.

Possibly, we'd want to invent a new acceptor API, to allow an acceptor to 
indicate whether it wants to use this functionality or not.  I'd prefer to 
avoid this, because it would delay both GS2 and SCRAM, since they would 
notionally actually have to use the new interface (it wouldn't delay 
_implementaton_ of pure-SASL SCRAM, though).


>> Does anyone recall the use case for allowing CB to fail and falling
>> back to a security layer even in the presence of a channel?
>
> I can see a marginal advantage of falling back to a security layer in
> such case, but it might be just simpler to either ignore channel bindings
> and not have a security layer, or to always negotiate a security layer
> irrespective of providing channel bindings.

Yeah, I think the question of whether to negotiate a security layer ought 
to be independent of whether channel bindings succeed.  IMHO the simplest 
way to do this is to declare that neither GS2 nor SCRAM provides security 
layers, and that SASL applications ought to use TLS (or some other 
appropriate channel) and channel bindings.

-- 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 n1JC4Gdo012650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 05:04:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1JC4G6E012649; Thu, 19 Feb 2009 05:04:16 -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 n1JC4EvQ012643 for <[e-mail]>; Thu, 19 Feb 2009 05:04:15 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.14.232] (92.40.14.232.sub.mbb.three.co.uk [92.40.14.232])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 19 Feb 2009 12:04:13 +0000
Message-ID: <[e-mail]>
Date: Thu, 19 Feb 2009 12:03:53 +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: Jeffrey Hutzelman <[e-mail]>
CC: Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; 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>

Jeffrey Hutzelman wrote:

> --On Tuesday, February 17, 2009 04:44:16 PM -0600 Nicolas Williams 
> <[e-mail]> wrote:
>
>> So what makes GS2 not simple?  The fact that we chose to make the GS2
>> channel binding semantics different from the GSS-API's: we chose to make
>> channel binding success/failure affect the negotiation of security
>> layers.
>>
>> If we reconsider that one choice we could simplify GS2 enough that a
>> single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
>
> Personally, I'm fine with saying that channel binding must succeed if 
> the application provided bindings.

What should happen if the other end can't verify them, because it has no 
API for doing that?
I think this is going to be a very real problem in short to medium term, 
because TLS APIs suck (or undocumented, which is close to being the same 
thing).

So, I am Ok with the following semantics: if a channel bind is provided 
by one end and can be verified by the other end, then any failure to 
verify it causes authentication failure, but if the other end doesn't 
have the ability to verify channel bindings, then ignoring them is fine.

> Does anyone recall the use case for allowing CB to fail and falling 
> back to a security layer even in the presence of a channel?

I can see a marginal advantage of falling back to a security layer in 
such case, but it might be just simpler to either ignore channel 
bindings and not have a security layer, or to always negotiate a 
security layer irrespective of providing channel bindings.



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 n1JBoBwZ011515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 04:50:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1JBoB3s011514; Thu, 19 Feb 2009 04:50:11 -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 n1JBnxdl011495 for <[e-mail]>; Thu, 19 Feb 2009 04:50:10 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.14.232] (92.40.14.232.sub.mbb.three.co.uk [92.40.14.232])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 19 Feb 2009 11:49:56 +0000
Message-ID: <[e-mail]>
Date: Thu, 19 Feb 2009 11:49:34 +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: Nicolas Williams <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
References: <[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>

Nicolas Williams wrote:

>Perhaps we can just simplify GS2 enough that all concerns go away.
>
>The primary differences between the GSS-API and SASL:
>
>a) one is message-oriented (GSS), the other is stream-oriented (SASL);
>
>b) SASL client apps must send the name of the mech being used before
>   using it, while the GSS-API includes the "name" of the selected mech
>   in the first authentication message;
>
This might be a minor detail, but if understand correctly, GSS-API is 
using OIDs for naming, while SASL typically doesn't.

>c) SASL authentication message exchanges negotiate what security layers
>   will be used and maximum message sizes; the GSS-API does no such
>   negotiations;
>
>d) the GSS-API has channel binding, but it's all or nothing, and it's
>   optional; SASL has never had channel binding.
>
>e) terminology :)
>
>(a) is easy to address in a SASL/GSS bridge.
>(b) is easy to address in a SASL/GSS bridge.
>
I am not entirely sure what you call "bridge" in this case, but I tend 
to agree with your conclusion ;-).

>(c) is easy to addres by replacing security layers with channel binding
>    to TLS,
>
As a side note: we shouldn't be requiring TLS to be the only channel 
binding, even though we can recommend it.

>which has the added advantage of simplifying mechanisms and
>    making (a) not matter.
>  
>
Agreed.
I think draft-newman-auth-scram-gs2-00.txt already made the same choice.

>(d) matters only if we want channel binding in SASL, and I think we long
>    ago agreed we did, and if we re-open that question I believe we'll
>    again conclude that we want it.
>  
>
Agreed.

>(e) we can ignore :)
>  
>
I think this is mostly an editorial issue, which might require quite a 
bit of work.
But I agree it should be ignored for now.

>So what makes GS2 not simple?  The fact that we chose to make the GS2
>channel binding semantics different from the GSS-API's: we chose to make
>channel binding success/failure affect the negotiation of security
>layers.
>
>If we reconsider that one choice we could simplify GS2 enough that a
>single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
>
I agree that would make GS2 simpler, but I am not convinced that that 
would be enough to make SCRAM-as-GS2 satisfy Chris Newman's requirement 
on simplicity. But anyway, I am willing to participate and see what the 
result would be.

I think the extra complexity lies is the need to have authorization 
identity separate from the rest of SCRAM data (because it is transported 
by GS2 itself), this requires an extra hash for protecting it. The same 
applies to the channel binding data, but your proposal above addresses 
this to some extend.



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 n1J4ZwFu090289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 21:35:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1J4ZwwE090288; Wed, 18 Feb 2009 21:35:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1J4ZjGZ090280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 18 Feb 2009 21:35:56 -0700 (MST) (envelope-from [e-mail])
Received: from mm.wbb.net.cable.rogers.com (mm.wbb.net.cable.rogers.com [74.210.92.229]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n1J4Zgx4089999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 18 Feb 2009 20:35:43 -0800 (PST) (envelope-from [e-mail])
Date: Wed, 18 Feb 2009 20:35:36 -0800 (PST)
From: Lyndon Nerenberg <[e-mail]>
To: [e-mail]
Subject: A dignified burial for CRAM-MD5
Message-ID: <[e-mail]>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Organization: The Frobozz Magic Homing Pigeon Company
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on orthanc.ca
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>

Folks, it has been nearly a decade since the first move towards re-stating 
CRAM-MD5 as a SASL mechanism. It's obvious now that this will never 
happen.

It's also obvious that CRAM-MD5 has entrenched itself to the point where 
it's not going to go away any time soon (or late for that matter).

The global base of interoperable deployments says we don't need to 
issue a formal update to the specification. Frankly, anything that fits 
inside two pages of text and works this well deserves to be left well 
enough alone.

Since the SASL WG can't come to an agreement about the status of CRAM-MD5 
-- other than it's adamantly opposed to its moving forward on the 
standards track -- I think it's time for the WG to drop CRAM-MD5 from the 
work list. It's currently not a formal SASL mechanism, so abandonment by 
the WG is a valid solution.

This would leave RFC2195 in its present state, validating the existing 
CRAM-MD5 deployments. Beside that, I'm proposing to put together a new 
Informational RFC that documents the WGs concerns about the mechanism, and 
addresses the interoperability issues. (Kurt's draft has done much of this 
work already.)

--lyndon



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 n1J0Qt9k081459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 17:26:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1J0QtqJ081458; Wed, 18 Feb 2009 17:26:55 -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 n1J0Qhn9081450 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 18 Feb 2009 17:26:54 -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 n1J0QVET017394 for <[e-mail]>; Wed, 18 Feb 2009 16:26:43 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; format=flowed; charset=us-ascii
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <[e-mail]> for [e-mail]; Wed, 18 Feb 2009 16:26:30 -0800 (PST)
Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <[e-mail]>; Wed, 18 Feb 2009 16:26:21 -0800 (PST)
Date: Wed, 18 Feb 2009 16:26:19 -0800
From: Chris Newman <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-reply-to: <[e-mail]>
To: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-id: <77521CD8A69FA47CD08FBB83@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
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 have evaluated both specifications in detail and reviewed the list 
traffic.

Brief conclusions:

Given a choice between these two approaches I oppose auth-scram-gs2-00.txt 
and support auth-scram-09.txt.

However, I believe the WG should evaluate the proposal Nico made on 2/17. 
The crux of that proposal is to change GS2 to remove support for SASL 
security layers and remove use of the GSS_Wrap function (which adds the 
unnecessary hash operation).  Doing so is likely to simplify auth-scram-gs2 
to the point where I would be comfortable with that approach.

Technical basis for my position:

I recognize some benefit from having a GSSAPI implementation of SCRAM 
visible through a GS2 SASL mechanism interoperate with a pure SASL SCRAM 
implementation.  However, if there were separate GSSAPI SCRAM and SASL 
SCRAM mechanisms, I believe implementers would make them interoperate when 
it was important to do so, just as some SASL implementers have supported 
non-standard SASL mechanisms like LOGIN, GSS-SPNEGO, and NTLM.  So I 
consider that benefit to be "modest".

The present formulation of auth-scram-gs2-00 is significantly more complex 
than auth-scram-09 (ABNF is roughly twice the size).  This additional 
complexity provides no _functionality_ improvements over scram-08 but 
requires additional hash-function computation and verification, extra 
binary encoding, and additional escaping.  The additional hash-function 
computation, in particular, has a non-obvious function and the mechanism 
would appear to work fine in most cases (succeeding with valid password, 
failing with invalid password) if an implementer simply chose not to verify 
the additional hash.  That creates a new opportunity for a security 
vulnerability in auth-scram-gs2 that does not exist in auth-scram.  That's 
over and above the additional security vulnerably risk from the necessarily 
larger code quantity.  So I consider the interop benefit to be outweighed 
by the security risk.

Further, I consider the need to have SCRAM supplant CRAM and DIGEST a 
higher priority than making SCRAM compatible with GS2.  The overall 
additional complexity of auth-scram-gs2-00 puts that primary goal in 
significant jeopardy to achieve what I consider a secondary goal.  That 
tradeoff is not acceptable to me.

If I understand Nico's proposal on 2/17 correctly, it could simplify the 
difference between auth-scram-09 and auth-scram-gs2 to just a blob at the 
beginning of the first client message.  If it's possible to do that, then I 
would support doing so.

		- Chris

--On February 5, 2009 21:14:04 +0000 Alexey Melnikov 
<[e-mail]> wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice between
> 2 SCRAM versions:
>  http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
>  http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman
> -auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-
> gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short
> explanation of why) to the mailing list, or say if you need more
> information.
>
> I would like to get all answers before February 19th, please.



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 n1IMYXM8076873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 15:34:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1IMYXhc076872; Wed, 18 Feb 2009 15:34:33 -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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1IMYMTH076860 for <[e-mail]>; Wed, 18 Feb 2009 15:34:33 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1IMYMuC023727 for <[e-mail]>; Wed, 18 Feb 2009 22:34:22 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 n1IMYMAV017000 for <[e-mail]>; Wed, 18 Feb 2009 15:34:22 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1IMHsjm002542; Wed, 18 Feb 2009 16:17:54 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1IMHqbl002541; Wed, 18 Feb 2009 16:17:52 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 18 Feb 2009 16:17:52 -0600
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Message-ID: <[e-mail]>
References: <[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 Wed, Feb 18, 2009 at 05:17:19PM -0500, Jeffrey Hutzelman wrote:
> --On Tuesday, February 17, 2009 04:44:16 PM -0600 Nicolas Williams 
> <[e-mail]> wrote:
> 
> >(c) is easy to addres by replacing security layers with channel binding
> >    to TLS, which has the added advantage of simplifying mechanisms and
> >    making (a) not matter.
> 
> I'm certainly willing to do this.

Me too, as is Chris Newman (I checked with him off-line).

> 
> >So what makes GS2 not simple?  The fact that we chose to make the GS2
> >channel binding semantics different from the GSS-API's: we chose to make
> >channel binding success/failure affect the negotiation of security
> >layers.
> >
> >If we reconsider that one choice we could simplify GS2 enough that a
> >single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.
> 
> Personally, I'm fine with saying that channel binding must succeed if the 
> application provided bindings.  Does anyone recall the use case for 
> allowing CB to fail and falling back to a security layer even in the 
> presence of a channel?

I don't recall, but it'd sure simplify everything.

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 n1IMXwkk076850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 15:33:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1IMXw79076849; Wed, 18 Feb 2009 15:33:58 -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 n1IMXkVW076820 for <[e-mail]>; Wed, 18 Feb 2009 15:33:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.166] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 18 Feb 2009 22:33:44 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 Feb 2009 22:32:43 +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: Jeffrey Hutzelman <[e-mail]>
CC: Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; 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>

Jeffrey Hutzelman wrote:

> --On Monday, February 16, 2009 07:33:27 PM +0000 Alexey Melnikov 
> <[e-mail]> wrote:
>
>> Hallvard B Furuseth wrote:
>>
>>> Kurt Zeilenga writes:
>>>
>>> One reality check: I have no idea what kind of SASL implementations are
>>> out there.  Are there implementations that do not support GS2/GSS?
>>
>> I can't only talk for one implementation: CMU SASL doesn't provide
>> GSS-API interface, it is a pure SASL implementation.
>
> Huh?  Cyrus SASL definitely does support the "GSSAPI" mechanism; it is 
> implemented in terms of the GSS-API (that is, it is not a "pure SASL" 
> implementation in the sense we've been talking about for SCRAM).
>
> What it is not is an implementation of Kerberos or the GSS-API.

This is exactly what I said: Cyrus SASL consumes GSS-API, but doesn't 
provide one.



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 n1IMHQQU075855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 15: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 n1IMHQMO075854; Wed, 18 Feb 2009 15: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 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 n1IMHOnq075848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 18 Feb 2009 15:17:25 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.144] (68-246-242-185.pools.spcsdns.net [68.246.242.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1IMHJgE015419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 17:17:21 -0500 (EST)
Date: Wed, 18 Feb 2009 17:17:19 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Kurt Zeilenga <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[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
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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, February 17, 2009 04:44:16 PM -0600 Nicolas Williams 
<[e-mail]> wrote:

> (c) is easy to addres by replacing security layers with channel binding
>     to TLS, which has the added advantage of simplifying mechanisms and
>     making (a) not matter.

I'm certainly willing to do this.


> So what makes GS2 not simple?  The fact that we chose to make the GS2
> channel binding semantics different from the GSS-API's: we chose to make
> channel binding success/failure affect the negotiation of security
> layers.
>
> If we reconsider that one choice we could simplify GS2 enough that a
> single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.

Personally, I'm fine with saying that channel binding must succeed if the 
application provided bindings.  Does anyone recall the use case for 
allowing CB to fail and falling back to a security layer even in the 
presence of a channel?

-- 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 n1IM0o2M075048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 15:00:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1IM0oVF075047; Wed, 18 Feb 2009 15:00:50 -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 n1IM0mFV075041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 18 Feb 2009 15:00:49 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.144] (68-246-242-185.pools.spcsdns.net [68.246.242.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1IM0iUw014827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 17:00:46 -0500 (EST)
Date: Wed, 18 Feb 2009 17:00:44 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>
cc: SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <[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
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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, February 16, 2009 07:33:27 PM +0000 Alexey Melnikov 
<[e-mail]> wrote:

>
> Hallvard B Furuseth wrote:
>
>> Kurt Zeilenga writes:
>>
>>
>> One reality check: I have no idea what kind of SASL implementations are
>> out there.  Are there implementations that do not support GS2/GSS?
>>
> I can't only talk for one implementation: CMU SASL doesn't provide
> GSS-API interface, it is a pure SASL implementation.

Huh?  Cyrus SASL definitely does support the "GSSAPI" mechanism; it is 
implemented in terms of the GSS-API (that is, it is not a "pure SASL" 
implementation in the sense we've been talking about for SCRAM).

What it is not is an implementation of Kerberos or the 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 n1ILRggO073730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 14:27:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ILRgwI073729; Wed, 18 Feb 2009 14:27:42 -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 n1ILRf8g073723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 18 Feb 2009 14:27:41 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.144] (68-246-242-185.pools.spcsdns.net [68.246.242.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1ILRZ8x013739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 16:27:37 -0500 (EST)
Date: Wed, 18 Feb 2009 16:27:35 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: Arnt Gulbrandsen <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[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
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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 Thursday, February 12, 2009 08:22:45 AM -0600 Nicolas Williams 
<[e-mail]> wrote:

>
> On Thu, Feb 12, 2009 at 11:23:37AM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
>> > only for the krb5 mech, and will likely never be used again: the
>> > precedent will be clear that no one will care to build mechanisms for
>> > one framework and then have then automatically available for the other,
>> > thus it will never be done for any other mechanisms.
>>
>> I'm less convinced of that.  I want to see a password-based GSS-API
>> mechanism, which would be possible to use in SASL via GS2, so there will
>> be at least one.  I agree pure-SASL-SCRAM would set a precedent, but I
>> don't think it will prevent future work towards merging the GSS-API and
>> SASL frameworks.
>
> Why have multiple equivalent password-based mechanisms for SASL?
>
> No, if SCRAM-as-not-GS2 happens then it'd be a safe bet that GS2 will
> only ever be used for Kerberos V.

I don't think that's true.  The certainly will be a SCRAM-like GSS 
mechanism.  Such a mechanism will work with GS2, and I'm sure there will be 
people who will deploy it, if only because they want to consistently use 
GSS-SCRAM everywhere they can.  I also expect that GS2 will be used with 
PKU2U, as there currently is no public key SASL mechanism.

I don't think the unwillingness of the SASL community to develop dual-stack 
mechanisms for which SASL-foo and GS2+GSS-foo interoperate means that we 
should be unwilling to develop GSS-API mechanisms and use them with GS2.

-- 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 n1ILNrga073602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 14:23:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ILNr4n073601; Wed, 18 Feb 2009 14:23:53 -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 n1ILNfEB073593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 18 Feb 2009 14:23:52 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.144] (68-246-242-185.pools.spcsdns.net [68.246.242.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1ILNZ0s013613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 16:23:37 -0500 (EST)
Date: Wed, 18 Feb 2009 16:23:35 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Lyndon Nerenberg <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[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
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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>

Forgive me if this has already been addressed in the intervening weeks, but 
you seem to be laboring under some rather serious misconceptions here, and 
it is important that they be straightened out...


--On Sunday, February 08, 2009 05:17:25 PM -0800 Lyndon Nerenberg 
<[e-mail]> wrote:

> It seems to me that the SASL WG is hell bent upon adding as much
> complexity as they can to everything they touch. Good security demands
> the absolute greatest amount of simplicity as can be attained while
> fulfilling the desired level of protection. This endless stacking of
> layer upon layer of protocol API serves only to add complexity to
> something that needs to be as simple and understandable as possible. If a
> human cannot parse and understand the protocol specification, there isn't
> a hope in hell they will be able to write a secure implementation.

Misconception #1: There is endless stacking of protocol API's.

We are not designing protocol API's; we're designing protocols.  The design 
of SASL and its mechanisms does not dictate a particular API or a 
particular architecture.  It does not dictate that an implementation have 
the same layers of abstraction that the protocol does, and there are 
apparently any number of single-application, single-mechanism SASL 
implementations.


Misconception #2: Layering adds complexity and makes things harder to 
understand and harder to implement correctly.

On the contrary, layering is what makes it possible to understand and 
implement this stuff reasonably _at all_.  Imagine what the world would be 
like if your email application had to implement not only the email 
protocol, but also authentication, crypto, reliable transport, discovery of 
the server address, route selection, and preparation and transmission of 
packets onto the wire.  Don't laugh; things actually used to work that way.

More directly relevant, layering and abstraction make it _easier_, not 
harder, to understand and analyze the security properties of the protocol, 
by allowing each layer to be understood in terms of the properties provided 
by the layer below, rather than in terms of the primitive operations.




> I don't think GS2 even belongs inside the SASL framework. They both try
> to solve the same problem, therefore it's pointless (and redundent) for
> GS2 to exist inside SASL to begin with. The two should exist
> side-by-side, letting the application protocol developers make the
> tradeoff between code complexity and desired security.

Misconception #3: GS2 and SASL try to solve the same problem.

This is just flat-out not true.  GSS-API and SASL solve similar (arguably 
isomorphic) problems.  GS2 solves the problem of allowing GSS-API 
mechanisms to be used in SASL.  This allows application protocol developers 
and implementors to simply use SASL, while allowing users to take advantage 
of existing and future GSS-API mechanisms.  There is no extra complexity 
for application protocol developers or implementors, or even for SASL 
framework developers, because the abstraction means that all SASL 
mechanisms can be used in the same way.


> As for SCRAM vs. GS2-SCRAM, since the two cannot speak to each other on
> the wire they are by definition distinct and seperate protocols, and
> therefore demand distinct and seperate specficications. That much of the
> text might overlap doesn't change this fact. I realize it takes more work
> to write two seperate documents, but the onus upon this WG is to write
> specifications that above all else address the needs of the people who
> have to implement this stuff. Mixing two protocols in a single document
> is just slapping these people in the face.

Misconception #4: SCRAM implemented as a pure SASL mechanism does not 
interoperate with SCRAM implemented as a GSS-API mechanism and used with 
GS2.

Again, completely untrue.  The entire point is that they _do_ interoperate. 
This is accomplished by having a single document which specifies both a 
SASL mechanism and a GSS-API mechanism, with the property that when the 
GSS-API mechanism is used with GS2, it interoperates with the SASL 
mechanism.

This is _really_ important.

It means that implementors who just want to add a SASL mechanism to their 
framework, or who want to implement a single-mechanism application, can do 
so, and need know nothing about GS2 or GSS-API or the "complexity" thereof.

It also means that if I have an existing appplication which uses an 
existing SASL framework, and I have a GS2 plugin for that framework, then I 
can use any GSS-API mechanism I have lying around.  If the mechanism I 
choose to use is SCRAM, it will interoperate with the single-mechanism 
application described above.

Now, that second method may seem like a lot of complexity to you, and it 
would be if you were writing an application that was going to be completely 
unable to use any mechansim other than SCRAM.  But what it does is allow 
you to write an application that uses SCRAM or any other SASL mechanism or 
any other GSS-API mechanism, all while doing _less_ work than you would do 
in writing the single-mechanism application.  This is because the SASL, 
GS2, GSS-API, SCRAM, and other mechanism implementations can all be done by 
different people and are all reusable, as is the application.



Now, there may remain one point of confusion.

Alexey pointed at two documents describing two versions of the SCRAM 
protocol.  The protocols described by the two documents do _not_ 
interoperate, which is OK, because we're only adopting one of them.  The 
_plan_ is not to define a pure SASL mechanism based on one document and a 
GSS-API mechanism based on the other, or a pure SASL mechansim based on one 
document and a SASL mechanism based on the other plus GS2.

The plan is to _either_

(1) Define _only_ a pure SASL mechanism based on the first document, and 
tell people who want a secure, password-based mechanism for non-SASL 
GSS-API applications like NFS that they are SOL because the IETF doesn't 
care about their needs, _or_

(2) Define _both_ a pure SASL mechanism _and_ a GSS-API mechanism, both 
based on the second document, such that SCRAM will be available for both 
SASL applications and non-SASL GSS-API applications, and the GSS-API 
mechanism combined with GS2 will interoperate with the pure SASL mechanism.


Note that if this WG chooses option (1), it will almost certainly result in 
the submission of an individual document describing an GSS-API mechanism 
which is based on SCRAM and which can be used with GS2 (because _any_ 
GSS-API mechanism can be used with GS2), but which when used with GS2 will 
_not_ interoperate with the pure-SASL mechanism defined in this WG.  One 
effect of this is that, in environments where both the SASL and GSS-API 
mechanisms are present, users will have a choice of using SASl-SCRAM or 
GS2+GSS-SCRAM, and the two will not interoperate.

-- 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 n1IE6uEF052290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 07:06:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1IE6uAK052289; Wed, 18 Feb 2009 07:06:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1IE6iu7052276 for <[e-mail]>; Wed, 18 Feb 2009 07:06:55 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Wed, 18 Feb 2009 14:07:40 +0000
Subject: SCRAM-HMAC-<<hash>> vs GS2-<<whatever>>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 18 Feb 2009 14:06:37 +0000
From: Dave Cridland <[e-mail]>
To: <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
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 not subscribed to the list, please copy me in on replies.

As someone who's spent a considerable time lately working with client  
developers of both MUAs and more recently XMPP, I'd like to describe  
what happens in those communities, particularly for XMPP.

XMPP's MTI SASL mechanism is currently DIGEST-MD5. This has to  
change. Operators and developers alike want a mechanism that doesn't  
store passwords in plaintext and doesn't send them in the clear  
either. SCRAM fits the bill very nicely, and is also relatively  
simple to code. Most client developers, especially, write their SASL  
mechanisms themselves - no libraries used - so a mechanism which is  
relatively straightforward to code in a number of common languages is  
important to us.

The GS2-<<whatever>> variant isn't much harder - although I suspect  
it is marginally more complex after reviewing them both. However, I  
feel strongly that although from a technical perspective there's  
little difference, the naming and use of GS2 will have a significant  
impact on deployment. In particular:

1) The simple fact it's using GSSAPI is enough to put many people off.

2) The name, by not being recognisable, would, I suspect, tend to  
mean that client developers don't notice the deployment, and won't  
follow up to see what the mechanism is. A SCRAM-HMAC-* name would,  
after all, be noticed much more easily in protocol logs, etc.

3) A SCRAM-HMAC-* name allows for new hash support to be obvious, and  
moreover allows for some implementations to switch in new hashes much  
more easily, by simple switching based on the name. GS2-<<whatever>>  
doesn't allow a developer to find out what hashes are supported very  
easily - indeed, the encrypted name means a brute-force attack is  
required.

None of this argues against there being a SCRAM-compatible GSSAPI  
mechanism, of course, but it does argue that a pure-SASL mechanism is  
useful to make available, and in some respects is actually going to  
be more secure, if only due to increased deployment and hash agility  
that's acted upon.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



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 n1HMrDAv015724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 15:53:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HMrDmT015723; Tue, 17 Feb 2009 15:53:13 -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 n1HMrCAp015717 for <[e-mail]>; Tue, 17 Feb 2009 15:53:13 -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 n1HMrC3Z009698 for <[e-mail]>; Tue, 17 Feb 2009 22:53: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 n1HMrCbl053777 for <[e-mail]>; Tue, 17 Feb 2009 15:53:12 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1HMiHkL001881; Tue, 17 Feb 2009 16:44:17 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1HMiGoQ001880; Tue, 17 Feb 2009 16:44:16 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Feb 2009 16:44:16 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Or: simplifying GS2 (Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

Perhaps we can just simplify GS2 enough that all concerns go away.

The primary differences between the GSS-API and SASL:

a) one is message-oriented (GSS), the other is stream-oriented (SASL);

b) SASL client apps must send the name of the mech being used before
   using it, while the GSS-API includes the "name" of the selected mech
   in the first authentication message;

c) SASL authentication message exchanges negotiate what security layers
   will be used and maximum message sizes; the GSS-API does no such
   negotiations;

d) the GSS-API has channel binding, but it's all or nothing, and it's
   optional; SASL has never had channel binding.

e) terminology :)

(a) is easy to address in a SASL/GSS bridge.
(b) is easy to address in a SASL/GSS bridge.
(c) is easy to addres by replacing security layers with channel binding
    to TLS, which has the added advantage of simplifying mechanisms and
    making (a) not matter.
(d) matters only if we want channel binding in SASL, and I think we long
    ago agreed we did, and if we re-open that question I believe we'll
    again conclude that we want it.
(e) we can ignore :)

So what makes GS2 not simple?  The fact that we chose to make the GS2
channel binding semantics different from the GSS-API's: we chose to make
channel binding success/failure affect the negotiation of security
layers.

If we reconsider that one choice we could simplify GS2 enough that a
single specification of SCRAM-as-a-GSS-API mechanism will satisfy all.

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 n1HM3i5x013658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 15:03:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HM3iAK013657; Tue, 17 Feb 2009 15:03:44 -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 n1HM3XOP013649 for <[e-mail]>; Tue, 17 Feb 2009 15:03:43 -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 n1HM3WwI019334 for <[e-mail]>; Tue, 17 Feb 2009 22:03:32 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 n1HM3Wdp017076 for <[e-mail]>; Tue, 17 Feb 2009 15:03:32 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1HLsbgY001837; Tue, 17 Feb 2009 15:54:37 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1HLsaSW001836; Tue, 17 Feb 2009 15:54:36 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Feb 2009 15:54:36 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[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, Feb 17, 2009 at 01:22:49PM -0800, Kurt Zeilenga wrote:
> >The only alternatives are:
> >
> >a) no GS2 (or limited to specific GSS mechanisms which will never be
> >  available as pure SASL, non-GS2 mechs);
> >b) no more pure SASL, non-GS2 mechs;
> >c) doubly-specified SASL mechs (once as pure SASL spec of a GS2 mech,
> >  the other as a pure GSS mech).
> >
> >All of these options suck.
> 
> Though I might not necessarily agree with your reasons, I can agree  
> that the above options do suck.  That's why I haven't suggested  
> anything of the kind, and do oppose making GS2-SASL definitive in  
> shape or form.

Note that (b) is effectively what the GS2 crowd (Simon, Sam, myself,
...) are proposing, though applied to SCRAM only.

Also, (a) will lead to multiple specs and implementations of what should
be pretty much the same mechanism: once for GSS, once for SASL.
Different mechs using similar messages and the same credentials.  The
difference between (a) and (c) is that (c) leads to multiple specs but
not multiple implementations.  (b) is the least sucky option... unless
you count RFC pages.

There are no good answers to this poll.

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 n1HLaYRJ012338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 14:36:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HLaYQR012337; Tue, 17 Feb 2009 14:36:34 -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 n1HLaNkB012326 for <[e-mail]>; Tue, 17 Feb 2009 14:36:34 -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 83C094AC75; Tue, 17 Feb 2009 22:36:22 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1234906582-9030-1/6/163 (4 recipients); Tue, 17 Feb 2009 22:36:22 +0100
Message-Id: <L2DUDtTLTVSEW1cGAOuuBQ.md5@lochnagar>
Date: Tue, 17 Feb 2009 22:37:34 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Subject: Re: SASL interop event (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar> <[e-mail]> <[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>

Kurt Zeilenga writes:
> During at least one of the LDAP interop events, we specifically tested 
>  SASL/DIGEST-MD5 interoperability.  It didn't go well.

Not surprised. I helped write two digest-md5 implementations and they 
don't always interoperate. This is not something I'm proud of.

That experience heightened my general suspicion of unnecessary 
complexity, so I don't think this posting is off-topic.

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 n1HLN6bK011704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 14:23:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HLN6wc011703; Tue, 17 Feb 2009 14:23:06 -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 n1HLMs3c011673 for <[e-mail]>; Tue, 17 Feb 2009 14:23:05 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 21:22:53 +0000
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 13:22:49 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 17, 2009, at 11:51 AM, Nicolas Williams wrote:

>
> On Tue, Feb 17, 2009 at 11:19:49AM -0800, Kurt Zeilenga wrote:
>>> We all agree that we want a SASL and a GSS-API mechanism that is
>>> password based and can share credential forms.
>>>
>>> The issue is: one mechanism, or two.
>>
>> Well, personally, I think there will be a GSS-API SCRAM mechanism
>> regardless of what this WG does, and hence a SASL-GS2-SCRAM mechanism
>> will become available, and specified on the standards track.


I have a feeling there will also be a simple SCRAM-based SASL  
mechanism regardless as well, but not necessarily documented on the  
Standards Track.

>> The question to me is whether we
>>
>> a:
>>   only document how to implement that mechanism directly (without
>> implementing GS2, GSS-API, and the GSS-API SCRAM mechanism).
>> b:
>>   only document an native SASL/SCRAM mechanism
>> c:
>>   do both
>>
>> I'm currently leaning towards c, though I'm trying to keep an open
>> mind towards b.
>
> (c) sounds like a recipe for: extra work and non-interop.

In (c), my assumption would be that SASL/SCRAM and SASL/GS2-SCRAM are  
two separate mechanisms, each with their own name. I would only claim  
they are based on the same technology, not that they were the same  
mechanism.  This would allow at least some reuse of some expertise,  
and possible certain code elements.

>>> I believe that this progression can result in correct  
>>> specifications:
>>> first specify the reduced, pure SASL version of SCRAM-as-GS2, then
>>> specify the pure GSS-API mechanism.
>>
>> We have what some believe is a "reduced, pure SASL version of
>> SCRAM-as- GS2", it seems time for "the pure GSS-API mechanism"
>> specification.
>
> I can't do it in time for the upcomming meeting.  Sorry.

Understand.

> And I don't think it should be a requirement, and I don't think  
> you're in a position
> to make it a requirement.

I was making a suggestion, not a requirement.

>
>
>>> I do, because I believe that the GSS version of the spec won't
>>> necessarily help establish that the pure SASL version of SCRAM-as-
>>> GS2 is correct.  See above.
>>
>> I don't see why a SASL mechanism RFC should be definitive over a GSS-
>> API mechanism for use, in say, NFS.  The GSS-API SCRAM specification
>
> Nobody said that.

Have never claimed any said that, I guess I won't dispute your  
statement.

I'm just stating an argument as why I think the GSS-API SCRAM  
specification needs to be definitive over the GS2-SCRAM specification.

> The pure GSS spec will have to be done.

That I don't doubt.

> You want it now, and I'm saying it needn't be a requirement right now.

I agree with both of these statements.  But I still hold my opinion  
regard what I can rely on in absence of a GSS-API SCRAM specification.

> Moreover, you won't get it (unless Simon or Sam step up and do it).

Oh well.

>> ought to be definitive.  The GS2-SCRAM ought to be an Informational
>> RFC describing an alternative implementation approach.
>
> That is the crux.  The pure SASL crowd scoffs at having to understand

> the GSS-API in order to implement SCRAM, thus the pure SASL
> specification of SCRAM-as-GS2 had better be Normative.

For GS2-SASL, I certainly have no problem with it being Informational.
But then I want a separate SASL/SCRAM mechanism.

> The pure GSS-API
> version will have to be as well, which imported via GS2 effectively
> results in two Normative specifications of the same mechanism.  That
> sounds like a recipe for trouble.

I do agree that this is a recipe for trouble.

> The only alternatives are:
>
> a) no GS2 (or limited to specific GSS mechanisms which will never be
>   available as pure SASL, non-GS2 mechs);
> b) no more pure SASL, non-GS2 mechs;
> c) doubly-specified SASL mechs (once as pure SASL spec of a GS2 mech,
>   the other as a pure GSS mech).
>
> All of these options suck.

Though I might not necessarily agree with your reasons, I can agree  
that the above options do suck.  That's why I haven't suggested  
anything of the kind, and do oppose making GS2-SASL definitive in  
shape or form.

-- 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 n1HKBOhI007662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 13: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 n1HKBOQd007661; Tue, 17 Feb 2009 13: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 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 n1HKBDZq007647 for <[e-mail]>; Tue, 17 Feb 2009 13:11:24 -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 n1HKBDhK029870 for <[e-mail]>; Tue, 17 Feb 2009 20:11:13 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 n1HKBDmk062850 for <[e-mail]>; Tue, 17 Feb 2009 13:11:13 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1HK2IfJ001661; Tue, 17 Feb 2009 14:02:18 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1HK2I93001660; Tue, 17 Feb 2009 14:02:18 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Feb 2009 14:02:18 -0600
From: Nicolas Williams <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[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, Feb 17, 2009 at 08:55:40PM +0100, Hallvard B Furuseth wrote:
> >    thus we can't expect them to review for wire compatibility of the
> >    two specs;
> 
> Indeed.  A brief page count says SCRAM-GS2 nearly doubles the amount of
> Scram background material, and multiplies the to-read pile by 7+ for a
> non-GSS person who knows the rest and just needed to read SCRAM itself.
> Depending on where you cut off what to count, anyway.
> 
>   Pages Documents
>    18   scram
>   150   sasl + saslprep + stringprep sans chartables
>         + hmac + sha-1 + channel bindings + base64 + utf-8
>   137   gs2 + gss-api + 2 more scram pages

GS2 has a lot of informative pages describing actual wire flows to help
the reader.  The point: page count is not a definitive measure of
complexity, not remotely.  You should also add to your page count all
the pages of API documentation you need to read in order to implement
SASL on your target platform.  And so on.  We all have to deal with
complexity.  Here we have some trade-offs with regards to complexity;
please see my reply to Kurt just a few minutes ago for details.

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 n1HK8TZn007356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 13:08:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HK8Tg9007355; Tue, 17 Feb 2009 13:08:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1HK8Rnc007347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 13:08:28 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LZWF0-0003Qd-Ar; Tue, 17 Feb 2009 21:08:26 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LZWF0-0006MU-3k; Tue, 17 Feb 2009 21:08:26 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LZWF0-0006YJ-2N; Tue, 17 Feb 2009 21:08:26 +0100
Message-Id: <[e-mail]>
From: Hallvard B Furuseth <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 17 Feb 2009 21:08:26 +0100
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 9FF9402552BC3D6C8743F7DB96C7FB8038A5CC21
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1392 max/h 8 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:
> Even if the HMAC is only a half-baked security layer, presumably it's
> better than nothing for apps that just take what they can get from the
> easily available mechanism(s).  If so, on unprotected connections
> SCRAM-GS2 looked weaker than SCRAM because it moved authzid out of the
> hash.
>
> Unless "gs2-to-be-protected" in the grammar is indeed intended to be
> protected.  But now you are talking as if maybe security layers need not
> be specified.

Uh, just to clarify: Obviously it's not critical to remove of a bit of
half-bakedness, if that's what it is.  Just a point to consider.  Now
that I'm trying to get my scram review notes into shape, there is a bit
of half-bakedness in several of the feature claims the SCRAM draft is
making.  I'll get these notes out the door Real Soon Now.

-- 
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 n1HK0h5s006850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 13:00:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HK0hhI006849; Tue, 17 Feb 2009 13:00:43 -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 n1HK0g9M006843 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 13:00:43 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1HK0gMQ018052 for <[e-mail]>; Tue, 17 Feb 2009 20:00:42 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 n1HK0gU8054723 for <[e-mail]>; Tue, 17 Feb 2009 13:00:42 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1HJpl36001649; Tue, 17 Feb 2009 13:51:47 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1HJpkiM001648; Tue, 17 Feb 2009 13:51:46 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Feb 2009 13:51:46 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[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, Feb 17, 2009 at 11:19:49AM -0800, Kurt Zeilenga wrote:
> >We all agree that we want a SASL and a GSS-API mechanism that is
> >password based and can share credential forms.
> >
> >The issue is: one mechanism, or two.
> 
> Well, personally, I think there will be a GSS-API SCRAM mechanism  
> regardless of what this WG does, and hence a SASL-GS2-SCRAM mechanism  
> will become available, and specified on the standards track.

All the more reason not to pursue a pure SASL, non-GS2 SCRAM.  Oterhwise
we might have situations like: client A that does only pure SASL,
non-GS2 SCRAM failing to use SCRAM with servers that support only the
GSS-API SCRAM mechanism through GS2.

> The question to me is whether we
> 
> a:
>    only document how to implement that mechanism directly (without  
> implementing GS2, GSS-API, and the GSS-API SCRAM mechanism).
> b:
>    only document an native SASL/SCRAM mechanism
> c:
>    do both
> 
> I'm currently leaning towards c, though I'm trying to keep an open  
> mind towards b.

(c) sounds like a recipe for: extra work and non-interop.

> >I believe that this progression can result in correct specifications:
> >first specify the reduced, pure SASL version of SCRAM-as-GS2, then
> >specify the pure GSS-API mechanism.
> 
> We have what some believe is a "reduced, pure SASL version of
> SCRAM-as- GS2", it seems time for "the pure GSS-API mechanism"
> specification.

I can't do it in time for the upcomming meeting.  Sorry.  And I don't
think it should be a requirement, and I don't think you're in a position
to make it a requirement.

> >I do, because I believe that the GSS version of the spec won't
> >necessarily help establish that the pure SASL version of SCRAM-as-
> >GS2 is correct.  See above.
> 
> I don't see why a SASL mechanism RFC should be definitive over a GSS- 
> API mechanism for use, in say, NFS.  The GSS-API SCRAM specification  

Nobody said that.  The pure GSS spec will have to be done.  You want it
now, and I'm saying it needn't be a requirement right now.  Moreover,
you won't get it (unless Simon or Sam step up and do it).

> ought to be definitive.  The GS2-SCRAM ought to be an Informational  
> RFC describing an alternative implementation approach.

That is the crux.  The pure SASL crowd scoffs at having to understand
the GSS-API in order to implement SCRAM, thus the pure SASL
specification of SCRAM-as-GS2 had better be Normative.  The pure GSS-API
version will have to be as well, which imported via GS2 effectively
results in two Normative specifications of the same mechanism.  That
sounds like a recipe for trouble.  The only alternatives are:

a) no GS2 (or limited to specific GSS mechanisms which will never be
   available as pure SASL, non-GS2 mechs);
b) no more pure SASL, non-GS2 mechs;
c) doubly-specified SASL mechs (once as pure SASL spec of a GS2 mech,
   the other as a pure GSS mech).

All of these options suck.  (a) sucks because it means extra
implementation work for those of us who have SASL and GSS-API stacks
(that's every OS vendor/distro maintainer out there).  (b) sucks for the
pure SASL crowd because it means learning the GSS-API and acquiring a
GSS-API stack.  (c) sucks, but only if we make a mistake.

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 n1HJtu1p006540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 12:55:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HJtuYe006539; Tue, 17 Feb 2009 12:55:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1HJthGo006529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 12:55:55 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LZW2f-0004OL-9N; Tue, 17 Feb 2009 20:55:41 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LZW2f-0003GR-0B; Tue, 17 Feb 2009 20:55:41 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LZW2e-0006Ww-V5; Tue, 17 Feb 2009 20:55:40 +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, 17 Feb 2009 20:55:40 +0100
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: A624D9D5D9A822063D92C6294016C6EDDF33F2F5
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1391 max/h 8 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:
> Are you asserting that support for SCRAM w/o TLS is required?  If so,
> and if we have use such cases we wish to address, then yes, we'd need to
> specify the security layers in order to be complete.
> 
> But a) no one has made such an assertion,

I hope I misunderstand you.  Why would SCRAM require TLS?  Personally
I had not made the opposite assertion because it did not occur to me.

Apps have varying security requirements.  There are enough cases where
even plaintext passwords and no TLS is considered adequate.  I didn't
think SCRAM was only for apps far on the other side on the scale.

And now I remember why I tried to ask if HMAC(<StoredKey/ServerKey>,
AuthMessage) also doubles as an integrity protection layer:

Even if the HMAC is only a half-baked security layer, presumably it's
better than nothing for apps that just take what they can get from the
easily available mechanism(s).  If so, on unprotected connections
SCRAM-GS2 looked weaker than SCRAM because it moved authzid out of the
hash.

Unless "gs2-to-be-protected" in the grammar is indeed intended to be
protected.  But now you are talking as if maybe security layers need not
be specified.

> I'd rather we go with a pure SASL description of SCRAM as GS2 and let
> the GS2 proponents worry about ensuring that the result can be described
> as a GSS-API mechanism used through GS2.  There are several reasons for
> this:
> 
>  - pure SASL reviewers/implementors seem to have no patience for
>    anything related to the GSS-API,

Speaking for myself, I don't mind anything related to the GSS-API
or derived from it.  Why would I, when I don't know it?  However:

>    thus we can't expect them to review for wire compatibility of the
>    two specs;

Indeed.  A brief page count says SCRAM-GS2 nearly doubles the amount of
Scram background material, and multiplies the to-read pile by 7+ for a
non-GSS person who knows the rest and just needed to read SCRAM itself.
Depending on where you cut off what to count, anyway.

  Pages Documents
   18   scram
  150   sasl + saslprep + stringprep sans chartables
        + hmac + sha-1 + channel bindings + base64 + utf-8
  137   gs2 + gss-api + 2 more scram pages

-- 
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 n1HJJu26004820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 12:19:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HJJuwV004819; Tue, 17 Feb 2009 12:19:56 -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 n1HJJsBE004811 for <[e-mail]>; Tue, 17 Feb 2009 12:19:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 19:19:52 +0000
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 11:19:49 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 17, 2009, at 10:14 AM, Nicolas Williams wrote:

>
> On Tue, Feb 17, 2009 at 10:01:11AM -0800, Kurt Zeilenga wrote:
>> On Feb 17, 2009, at 9:19 AM, Nicolas Williams wrote:
>>> Are you asserting that support for SCRAM w/o TLS is required?
>>
>> Well, TLS had little to do with my above statement of incompleteness.
>
> It has everything to do with the one completeness issue that you have.
>
> Otherwise I don't see how your comment about completeness is  
> relevant to
> this discussion.
>
>> The above statement of incompleteness was more to do with
>> specification completeness, such as necessary to evaluate wire
>> compatibility, than feature completeness (such as inclusion of the  
>> GS2-
>> SASL security layer).
>
> I've addressed this.

Regrettable not to my personal satisfaction.

>
>
>> But I have noted that I would considered SASL/GS2-SCRAM w/o TLS as
>> being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being
>> feature incomplete.
>
> I can't parse this.

s/TLS/security layer/g in the above paragraph.

That is,

I think it fine for SASL/SCRAM not to offer security layers.
I think SASL/GS2-SCRAM without support for GS2 security layers as  
being feature incomplete.

>
>
>> This is because I see GS2 mechanisms offering a more robust feature
>> set than what some non-GS2 mechanisms might offer, and I see SASL/
>> SCRAM as offering a simple mechanism.
>
> Ignoring the GSS->SASL bridging aspect of GS2 the primary difference
> between GS2 and non-GS2 SASL mechs is this:
>
>    GS2 mechanisms support channel binding and negotiation of security
>    layers that is conditional on channel binding.
>
> That's it.
>
>> I obviously don't see this as an X vs. Y choice.  I rather have a
>> simple SASL/SCRAM native mechanism and a robust SASL/GS2-SCRAM than a
>> single mechanism which is neither simple nor robust.
>
> We all agree that we want a SASL and a GSS-API mechanism that is
> password based and can share credential forms.
>
> The issue is: one mechanism, or two.

Well, personally, I think there will be a GSS-API SCRAM mechanism  
regardless of what this WG does, and hence a SASL-GS2-SCRAM mechanism  
will become available, and specified on the standards track.

The question to me is whether we

a:
    only document how to implement that mechanism directly (without  
implementing GS2, GSS-API, and the GSS-API SCRAM mechanism).
b:
    only document an native SASL/SCRAM mechanism
c:
    do both

I'm currently leaning towards c, though I'm trying to keep an open  
mind towards b.

>
>
>>> If so,
>>> and if we have use such cases we wish to address, then yes, we'd
>>> need to
>>> specify the security layers in order to be complete.
>>
>> Same uses cases that GS2 security layers serve.
>
> Again, are you asserting that security layers are a requirement?

I think GS2-SCRAM ought to detail how to implement all features of the  
GS2/GSS-API/SCRAM mechanism. Where not feasible, GS2-SCRAM could  
instead discuss why it's not feature complete and the implications of  
this.

So, requirement is too strong of a word.  I see such feature  
completeness of GS2-SCRAM as a SHOULD not a MUST.

>>> Are you asking about completeness, or correctness? (or both?)
>>
>> Well, in my previous response was referring to completeness of
>> specifications in order to better ensure correctness of those
>> specifications.
>
> I believe that this progression can result in correct specifications:
> first specify the reduced, pure SASL version of SCRAM-as-GS2, then
> specify the pure GSS-API mechanism.

We have what some believe is a "reduced, pure SASL version of SCRAM-as- 
GS2",
it seems time for "the pure GSS-API mechanism" specification.

> The reason I believe this is that short of actual interop testing of
> implementations of each type we'll need to manually review the pure  
> SASL
> version of SCRAM-as-GS2 for compatibility with GS2 and with GSS-API
> semantics.

I would certainly agree that short of interoperability testing of  
implementations of both approaches the question of wire compatibility  
is in doubt.   Which is one of the reasons I favor two mechanisms  
names over one mechanism name.  I rather deal with two names for the  
same thing than one name for two close but significantly different  
things.

> Having the pure GSS version of SCRAM is not necessarily
> going to help in that manual review (I say this as a GSS-API expert).
>
>>> I'd rather we go with a pure SASL description of SCRAM as GS2 and  
>>> let
>>> the GS2 proponents worry about ensuring that the result can be
>>> described
>>> as a GSS-API mechanism used through GS2.
>>
>> From an initial engineering point of view, I think it was reasonable
>> to design GS2-SCRAM before GSS-API SCRAM.
>>
>> But as a specification progression point of view, I don't see it
>> reasonable to progress/publish GS2-SCRAM prior to the progression/
>> publication of SASL/GS2 and GSS-API SCRAM.
>
> I do, because I believe that the GSS version of the spec won't
> necessarily help establish that the pure SASL version of SCRAM-as- 
> GS2 is
> correct.  See above.

I don't see why a SASL mechanism RFC should be definitive over a GSS- 
API mechanism for use, in say, NFS.  The GSS-API SCRAM specification  
ought to be definitive.  The GS2-SCRAM ought to be an Informational  
RFC describing an alternative implementation approach.

>
>
>>> There are several reasons for
>>> this:
>>>
>>> - pure SASL reviewers/implementors seem to have no patience for
>>> anything related to the GSS-API, thus we can't expect them to review
>>> for wire compatibility of the two specs;
>>
>> Yes, but I find it hard to rely on GS2 / GSS-API experts claims  
>> when I
>> know they don't yet have a GSS-API SCRAM specification to review.
>
> We don't need it.

While I respect your personal opinion in this area, your statement  
here doesn't change my personal opinion as stated 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 n1HIO9O5001521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 11:24:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HIO9ef001520; Tue, 17 Feb 2009 11:24:09 -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 ([62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1HIO8qo001485 for <[e-mail]>; Tue, 17 Feb 2009 11:24:08 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 18:23:37 +0000
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 10:23:33 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 17, 2009, at 10:01 AM, Kurt Zeilenga wrote:

> I obviously don't see this as an X vs. Y choice.


I also rather have two names for what is the same bits on the wire  
than one name for two different sets on the wire.

I guess I'm bit pessimistic about our abilities to ensure two separate  
specifications, for two separate implementation approaches, will yield  
wire compatibility over the life time of the specifications (including  
subsequent revisions, extensions, etc.).

-- 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 n1HINPwc001477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 11: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 n1HINPSn001476; Tue, 17 Feb 2009 11: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-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 n1HINOeW001470 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 11:23:24 -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 n1HINN4O018304 for <[e-mail]>; Tue, 17 Feb 2009 18:23:24 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 n1HINNdr010403 for <[e-mail]>; Tue, 17 Feb 2009 11:23:23 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1HIETtu001616; Tue, 17 Feb 2009 12:14:29 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1HIETIZ001615; Tue, 17 Feb 2009 12:14:29 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Feb 2009 12:14:29 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[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, Feb 17, 2009 at 10:01:11AM -0800, Kurt Zeilenga wrote:
> On Feb 17, 2009, at 9:19 AM, Nicolas Williams wrote:
> >Are you asserting that support for SCRAM w/o TLS is required?
> 
> Well, TLS had little to do with my above statement of incompleteness.   

It has everything to do with the one completeness issue that you have.

Otherwise I don't see how your comment about completeness is relevant to
this discussion.

> The above statement of incompleteness was more to do with  
> specification completeness, such as necessary to evaluate wire  
> compatibility, than feature completeness (such as inclusion of the GS2- 
> SASL security layer).

I've addressed this.

> But I have noted that I would considered SASL/GS2-SCRAM w/o TLS as  
> being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being  
> feature incomplete.

I can't parse this.

> This is because I see GS2 mechanisms offering a more robust feature  
> set than what some non-GS2 mechanisms might offer, and I see SASL/ 
> SCRAM as offering a simple mechanism.

Ignoring the GSS->SASL bridging aspect of GS2 the primary difference
between GS2 and non-GS2 SASL mechs is this:

    GS2 mechanisms support channel binding and negotiation of security
    layers that is conditional on channel binding.

That's it.

> I obviously don't see this as an X vs. Y choice.  I rather have a  
> simple SASL/SCRAM native mechanism and a robust SASL/GS2-SCRAM than a  
> single mechanism which is neither simple nor robust.

We all agree that we want a SASL and a GSS-API mechanism that is
password based and can share credential forms.

The issue is: one mechanism, or two.

> >If so,
> >and if we have use such cases we wish to address, then yes, we'd  
> >need to
> >specify the security layers in order to be complete.
> 
> Same uses cases that GS2 security layers serve.

Again, are you asserting that security layers are a requirement?

> >Are you asking about completeness, or correctness? (or both?)
> 
> Well, in my previous response was referring to completeness of  
> specifications in order to better ensure correctness of those  
> specifications.

I believe that this progression can result in correct specifications:
first specify the reduced, pure SASL version of SCRAM-as-GS2, then
specify the pure GSS-API mechanism.

The reason I believe this is that short of actual interop testing of
implementations of each type we'll need to manually review the pure SASL
version of SCRAM-as-GS2 for compatibility with GS2 and with GSS-API
semantics.  Having the pure GSS version of SCRAM is not necessarily
going to help in that manual review (I say this as a GSS-API expert).

> >I'd rather we go with a pure SASL description of SCRAM as GS2 and let
> >the GS2 proponents worry about ensuring that the result can be  
> >described
> >as a GSS-API mechanism used through GS2.
> 
> From an initial engineering point of view, I think it was reasonable  
> to design GS2-SCRAM before GSS-API SCRAM.
> 
> But as a specification progression point of view, I don't see it  
> reasonable to progress/publish GS2-SCRAM prior to the progression/ 
> publication of SASL/GS2 and GSS-API SCRAM.

I do, because I believe that the GSS version of the spec won't
necessarily help establish that the pure SASL version of SCRAM-as-GS2 is
correct.  See above.

> >There are several reasons for
> >this:
> >
> >- pure SASL reviewers/implementors seem to have no patience for
> >  anything related to the GSS-API, thus we can't expect them to review
> >  for wire compatibility of the two specs;
> 
> Yes, but I find it hard to rely on GS2 / GSS-API experts claims when I  
> know they don't yet have a GSS-API SCRAM specification to review.

We don't need it.  We need the pure SASL spec of SCRAM-as-GS2 and we can
work from that.

Short of actual interop testing you'll have to trust what reviewers say.

> >- there are GSS-API features that are not relevant to SASL/GS2 that we
> >  can leave out from the pure SASL description of SCRAM but should
> >  consider leaving in the pure GSS description of SCRAM.
> 
> Well, I think the GS2-SCRAM should at least discuss why it doesn't  
> detail how to implement certain features of the mechanism.  However, I  
> would favor a GS2-SCRAM that was more feature complete over one that  
> was less and am quite likely to argue for inclusion of certain  
> features (such as support for GS2 security layers) in GS-SASL.

I would too, but I don't believe that's necessary.

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 n1HIEDcj000727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 11:14:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HIED3B000726; Tue, 17 Feb 2009 11:14:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1HIEC0t000719 for <[e-mail]>; Tue, 17 Feb 2009 11:14:13 -0700 (MST) (envelope-from [e-mail])
Received: from wrk126.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 50F7C409EE; Tue, 17 Feb 2009 11:08:13 -0700 (MST)
Message-ID: <[e-mail]>
Date: Tue, 17 Feb 2009 11:14:11 -0700
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: [e-mail]
CC: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080105050102060503050403"
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>

This is a cryptographically signed message in MIME format.

--------------ms080105050102060503050403
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

IMHO Ned's perspective is broadly congruent with experience in the XMPP
community.

[e-mail] wrote:
> 
>> On Feb 16, 2009, at 9:26 AM, Hallvard B Furuseth wrote:
> 
>> > One reality check: I have no idea what kind of SASL implementations
>> > are
>> > out there.  Are there implementations that do not support GS2/GSS?
> 
>> Yes.  For instance, it's fairly common to implement a basic SASL
>> implementation when one only requires simple SASL mechanisms (e.g.,
>> EXTERNAL, PLAIN, CRAM-MD5).
> 
> Over the years we've done several separate implementations of SASL, both
> server
> and client, supporting a variety of SASL mechanisms: EXTERNAL, PLAIN,
> LOGIN,
> CRAM-MD5, DIGEST-MD5, etc. But none of them have ever supported GS2/GSS,
> either
> through our own code or through interfacing with public libraries.
> 
> Frankly, unless the quality of the publicly available code for GS2/GSS has
> improved by at least an order of magnitude since the last time I looked
> at it,
> there's no chance we'll ever support GS2/GSS directly through publicly
> available code. Putting that code in the middle of a complex, multithreaded
> client or server seems like a sure-fire recipe for disaster. If we
> absolutely
> had to have support for this we'd do it by talking to a separate, single
> threaded authentication server process using some sort of simple protocol.
> 
> As for writing our own, the last time I looked into this I'm afraid I
> could not
> make head nor tails of the specifications. Now, this was some time ago
> and the
> specifications may have improved since then. Or alternately, it could be
> due to
> my own stupidity, but as a point of comparison I'm someone who was able
> to code
> a full implementation of X.400-1988 and the specifications for that were
> IMO
> plenty clear enough to implement from.
> 
>> [I've done this myself a couple of
>> times.]  I would hope that SCRAM would have similar complexity to CRAM-
>> MD5, and hence implementable quite independently of so-called "SASL
>> libraries" and GS2 and GSS-API frameworks.
> 
> Indeed. Not having to use a library is a pretty significant win in a lot of
> cases. That's another reason why I'm strongly in favor of keeping the
> complexity in SCRAM to an absolute minimum.
> 
>                 Ned
> 


--------------ms080105050102060503050403
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC
BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT
aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG
EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q
UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN
AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm
K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e
whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci
bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/
+Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID
ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB
BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ
nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g
BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0
ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM
aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv
bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj
BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ
w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia
cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl
rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6
JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU
IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy
MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE
ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0
YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu
dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS
+GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b
KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C
RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA
sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB
zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe
dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD
ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG
AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB
FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC
AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0
aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0
dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au
c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S
BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK
EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3
l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi
qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE
jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T
UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN
BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx
MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp
BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR
z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv
HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK
/kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s
QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9
bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD
VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH
MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT
IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB
BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j
cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy
bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud
IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy
dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh
cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv
bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh
ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0
YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E
QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp
bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U
u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5
zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y
VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9
gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk
az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1
Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa
16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06
8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm
bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ
9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wOTAyMTcxODE0MTFaMCMGCSqGSIb3DQEJBDEWBBRaX7/MWYvirDljFlQEnIXm
I3MC7jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL
MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN
AQEBBQAEggEAGSUwP5i4qS4s3CcdMNL3q1d+8FtacI3JRTuOd2c9+iuNkfTID0A+5ZlPjqet
TPdljiah9Ub7lpq9QkSsjaB2x/F2MDjsU1/9o/zGILDwVDU8C2XjFYOP3Z+S0DWRJ95ajWG+
SKd0eEzONOujj+rOKy+Jm+jlvJvKy7UMGLDf8XNNczr8mcNNUoJyK60H1gpSl7UK87LSjPdl
0RPiT2p0n1yakAficSVyPo8TPkRHbVr279N9iJowlSjXsXHJp8D2N6MaiVG/JtJ+BZNRoijD
zXbYKHmD78egD/91gk69mVdHuU2drL2i9YRt6sjIlHyweX//+1ou4EXrNg90qMYPXQAAAAAA
AA==
--------------ms080105050102060503050403--



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 n1HI1IHE099710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 11:01:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HI1IJJ099709; Tue, 17 Feb 2009 11:01:18 -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 n1HI1G5Q099702 for <[e-mail]>; Tue, 17 Feb 2009 11:01:17 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 18:01:15 +0000
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 10:01:11 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 17, 2009, at 9:19 AM, Nicolas Williams wrote:

>
> On Tue, Feb 17, 2009 at 09:07:12AM -0800, Kurt Zeilenga wrote:
>> On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:
>>> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>>>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>>>> I think SASL + TLS is the common case, thus to fail to describe
>>>>> SCRAM
>>>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>>>> position to take so as to simplify that document.  Thus anyone  
>>>>> who'd
>>>>> want to implement SCRAM sec layers would have to read the GS2 and
>>>>> SCRAM-as-GSS-API-mech documents.
>>>>
>>>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>>>> IETF#74).
>>>
>>> It'd be good, yes, but, does that have anything to do with this  
>>> poll?
>>
>> Because the completeness of the GS2-SCRAM I-D is questionable to some
>> without a GSS-API SCRAM specification.
>
> Are you asserting that support for SCRAM w/o TLS is required?

Well, TLS had little to do with my above statement of incompleteness.   
The above statement of incompleteness was more to do with  
specification completeness, such as necessary to evaluate wire  
compatibility, than feature completeness (such as inclusion of the GS2- 
SASL security layer).

But I have noted that I would considered SASL/GS2-SCRAM w/o TLS as  
being feature incomplete.   I don't think SASL/SCRAM w/o TLS as being  
feature incomplete.

This is because I see GS2 mechanisms offering a more robust feature  
set than what some non-GS2 mechanisms might offer, and I see SASL/ 
SCRAM as offering a simple mechanism.

I obviously don't see this as an X vs. Y choice.  I rather have a  
simple SASL/SCRAM native mechanism and a robust SASL/GS2-SCRAM than a  
single mechanism which is neither simple nor robust.

> If so,
> and if we have use such cases we wish to address, then yes, we'd  
> need to
> specify the security layers in order to be complete.

Same uses cases that GS2 security layers serve.

>> That is, having a GSS-API SCRAM specification will allow for  
>> reviewers
>> to consider the question of whether GS2-SASL is wire compatible or
>> not, as opposed to simply relying on claims that it will be.
>
> Are you asking about completeness, or correctness? (or both?)

Well, in my previous response was referring to completeness of  
specifications in order to better ensure correctness of those  
specifications.

But with TLS, I refer to completeness of feature sets.


>> It may also tease out other issues, such as which specification is
>> definitive.
>
> I'd rather we go with a pure SASL description of SCRAM as GS2 and let
> the GS2 proponents worry about ensuring that the result can be  
> described
> as a GSS-API mechanism used through GS2.

 From an initial engineering point of view, I think it was reasonable  
to design GS2-SCRAM before GSS-API SCRAM.

But as a specification progression point of view, I don't see it  
reasonable to progress/publish GS2-SCRAM prior to the progression/ 
publication of SASL/GS2 and GSS-API SCRAM.

> There are several reasons for
> this:
>
> - pure SASL reviewers/implementors seem to have no patience for
>   anything related to the GSS-API, thus we can't expect them to review
>   for wire compatibility of the two specs;

Yes, but I find it hard to rely on GS2 / GSS-API experts claims when I  
know they don't yet have a GSS-API SCRAM specification to review.

> - there are GSS-API features that are not relevant to SASL/GS2 that we
>   can leave out from the pure SASL description of SCRAM but should
>   consider leaving in the pure GSS description of SCRAM.


Well, I think the GS2-SCRAM should at least discuss why it doesn't  
detail how to implement certain features of the mechanism.  However, I  
would favor a GS2-SCRAM that was more feature complete over one that  
was less and am quite likely to argue for inclusion of certain  
features (such as support for GS2 security layers) in GS-SASL.

-- 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 n1HHcEZR098142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 10:38:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HHcEWP098141; Tue, 17 Feb 2009 10:38:14 -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 n1HHc9v9098128 for <[e-mail]>; Tue, 17 Feb 2009 10:38:12 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 17:38:06 +0000
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 09:37:54 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:

>
> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>> I think SASL + TLS is the common case, thus to fail to describe  
>>> SCRAM
>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>> position to take so as to simplify that document.  Thus anyone who'd
>>> want to implement SCRAM sec layers would have to read the GS2 and
>>> SCRAM-as-GSS-API-mech documents.
>>
>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>> IETF#74).
>
> It'd be good, yes, but, does that have anything to do with this poll?

Aside from my previous comment (in which I was speaking as an  
individual), I'd like to make one comment here with my chair hat on.

One of my concerns with this straw poll is its finality, or lack  
thereof, in the face of incomplete documents.  Regardless of which I-D  
we choose (or both), if we later decide (for whatever reason) to  
significant change that I-D (or the other), it would be reasonable to  
allow re-opening of the question of this straw poll.  My nudging for  
the above (as well as other completeness issues) is, in part, an  
attempt to reduce the likelihood of subsequent significant change in  
this I-D.

-- 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 n1HHShno097748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 10:28:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HHShtK097747; Tue, 17 Feb 2009 10:28:43 -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 n1HHSW5p097734 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 10:28:42 -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 n1HHSVWH000866 for <[e-mail]>; Tue, 17 Feb 2009 17:28:31 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 n1HHSVUi027765 for <[e-mail]>; Tue, 17 Feb 2009 10:28:31 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1HHJZGE001586; Tue, 17 Feb 2009 11:19:35 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1HHJZhN001585; Tue, 17 Feb 2009 11:19:35 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Feb 2009 11:19:35 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[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, Feb 17, 2009 at 09:07:12AM -0800, Kurt Zeilenga wrote:
> On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:
> >On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
> >>On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
> >>>I think SASL + TLS is the common case, thus to fail to describe  
> >>>SCRAM
> >>>SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> >>>position to take so as to simplify that document.  Thus anyone who'd
> >>>want to implement SCRAM sec layers would have to read the GS2 and
> >>>SCRAM-as-GSS-API-mech documents.
> >>
> >>I think it would be good to have a GSSAPI-SCRAM I-D soon (before
> >>IETF#74).
> >
> >It'd be good, yes, but, does that have anything to do with this poll?
> 
> Because the completeness of the GS2-SCRAM I-D is questionable to some  
> without a GSS-API SCRAM specification.

Are you asserting that support for SCRAM w/o TLS is required?  If so,
and if we have use such cases we wish to address, then yes, we'd need to
specify the security layers in order to be complete.

But a) no one has made such an assertion, b) even then that does not
necessarily require that we have a document defining SCRAM-as-a-GSS-API-
mechanism immediately.

> That is, having a GSS-API SCRAM specification will allow for reviewers  
> to consider the question of whether GS2-SASL is wire compatible or  
> not, as opposed to simply relying on claims that it will be.

Are you asking about completeness, or correctness? (or both?)

> It may also tease out other issues, such as which specification is  
> definitive.

I'd rather we go with a pure SASL description of SCRAM as GS2 and let
the GS2 proponents worry about ensuring that the result can be described
as a GSS-API mechanism used through GS2.  There are several reasons for
this:

 - pure SASL reviewers/implementors seem to have no patience for
   anything related to the GSS-API, thus we can't expect them to review
   for wire compatibility of the two specs;

 - there are GSS-API features that are not relevant to SASL/GS2 that we
   can leave out from the pure SASL description of SCRAM but should
   consider leaving in the pure GSS description of SCRAM.

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 n1HHIZdk097276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 10:18:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HHIZSv097275; Tue, 17 Feb 2009 10:18:35 -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 n1HHIYlY097268 for <[e-mail]>; Tue, 17 Feb 2009 10:18:35 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 17 Feb 2009 17:18:33 +0000
Message-ID: <[e-mail]>
Date: Tue, 17 Feb 2009 17:17:55 +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: Kurt Zeilenga <[e-mail]>
CC: Nicolas Williams <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; 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>

Kurt Zeilenga wrote:

> On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:
>
>> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>>
>>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>>
>>>> I think SASL + TLS is the common case, thus to fail to describe  SCRAM
>>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>>> position to take so as to simplify that document.  Thus anyone who'd
>>>> want to implement SCRAM sec layers would have to read the GS2 and
>>>> SCRAM-as-GSS-API-mech documents.
>>>
>>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>>> IETF#74).
>>
>> It'd be good, yes, but, does that have anything to do with this poll?
>
> Because the completeness of the GS2-SCRAM I-D is questionable to some  
> without a GSS-API SCRAM specification.

This would need doing once we make a choice, but I don't think this is a 
prerequisite for making it.

> That is, having a GSS-API SCRAM specification will allow for 
> reviewers  to consider the question of whether GS2-SASL is wire 
> compatible or  not, as opposed to simply relying on claims that it 
> will be.

Just trust us :-).

> It may also tease out other issues, such as which specification is  
> definitive.




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 n1HHHGB2097183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 10:17:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HHHGmQ097182; Tue, 17 Feb 2009 10:17:16 -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 n1HHHFsT097174 for <[e-mail]>; Tue, 17 Feb 2009 10:17:15 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 17 Feb 2009 17:17:13 +0000
Message-ID: <[e-mail]>
Date: Tue, 17 Feb 2009 17:16:35 +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: Hallvard B Furuseth <[e-mail]>
CC: Kurt Zeilenga <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: SASL interop event  (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar> <[e-mail]> <[e-mail]> <[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>

Hallvard B Furuseth wrote:

>Kurt Zeilenga writes:
>  
>
>>During at least one of the LDAP interop events, we specifically tested  
>>SASL/DIGEST-MD5 interoperability.  It didn't go well.
>>    
>>
>Whee.  Details!  What problems where identified?  Which mistakes are we
>repeating now?
>  
>
Most of this should be in my draft "Digest to historic".




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 n1HHDSCe097017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 10:13:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HHDSL9097016; Tue, 17 Feb 2009 10:13:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1HHDF95096994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Feb 2009 10:13:27 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LZTVR-0002Rg-TH; Tue, 17 Feb 2009 18:13:13 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LZTVR-0004r1-MJ; Tue, 17 Feb 2009 18:13:13 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LZTVR-0006Dp-Fe; Tue, 17 Feb 2009 18:13:13 +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, 17 Feb 2009 18:13:13 +0100
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: SASL interop event  (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 431AB530D55F9CA761BB24E223425C18EE8A1E6A
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 1390 max/h 8 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>

Kurt Zeilenga writes:
> During at least one of the LDAP interop events, we specifically tested  
> SASL/DIGEST-MD5 interoperability.  It didn't go well.

Whee.  Details!  What problems where identified?  Which mistakes are we
repeating now?

-- 
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 n1HH7Jcb096633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 10:07:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HH7JHu096632; Tue, 17 Feb 2009 10:07:19 -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 n1HH7HBs096625 for <[e-mail]>; Tue, 17 Feb 2009 10:07:18 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 17:07:16 +0000
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 09:07:12 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 17, 2009, at 8:42 AM, Nicolas Williams wrote:

> On Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
>> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
>>> I think SASL + TLS is the common case, thus to fail to describe  
>>> SCRAM
>>> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
>>> position to take so as to simplify that document.  Thus anyone who'd
>>> want to implement SCRAM sec layers would have to read the GS2 and
>>> SCRAM-as-GSS-API-mech documents.
>>
>> I think it would be good to have a GSSAPI-SCRAM I-D soon (before
>> IETF#74).
>
> It'd be good, yes, but, does that have anything to do with this poll?


Because the completeness of the GS2-SCRAM I-D is questionable to some  
without a GSS-API SCRAM specification.

That is, having a GSS-API SCRAM specification will allow for reviewers  
to consider the question of whether GS2-SASL is wire compatible or  
not, as opposed to simply relying on claims that it will be.

It may also tease out other issues, such as which specification is  
definitive.

-- 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 n1HH7G5N096623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 10:07:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HH7GbH096622; Tue, 17 Feb 2009 10:07:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1HH75P9096602 for <[e-mail]>; Tue, 17 Feb 2009 10:07:15 -0700 (MST) (envelope-from [e-mail])
Received: from wrk126.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 77D60409EC; Tue, 17 Feb 2009 10:00:51 -0700 (MST)
Message-ID: <[e-mail]>
Date: Tue, 17 Feb 2009 10:06:49 -0700
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Kurt Zeilenga <[e-mail]>
CC: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: SASL interop event          (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
References: <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020601090808020904060103"
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>

This is a cryptographically signed message in MIME format.

--------------ms020601090808020904060103
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Kurt Zeilenga wrote:
> 
> On Feb 17, 2009, at 2:40 AM, Alexey Melnikov wrote:
> 
>> Arnt Gulbrandsen wrote:
>>
>>> Alexey
>>> (http://tools.ietf.org/html/draft-ietf-sasl-digest-to-historic) made
>>> me think there are _many_ digest-md5 implementations out there. Fifty
>>> or a hundred seem a more reasonable estimates than ten. If the number
>>> were ten or twenty, it would have been practical to gather a good
>>> fraction of the implentors for an interop event.
> 
> During at least one of the LDAP interop events, we specifically tested
> SASL/DIGEST-MD5 interoperability.  It didn't go well.

We have experienced significant inteorperability problems regarding
SASL/DIGEST-MD5 on the XMPP network, too.

Peter


--------------ms020601090808020904060103
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWZDCC
BzswggYjoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT
aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQTAeFw0wODA3MDIyMDQzMThaFw0wOTA3MDIyMDQzMThaMIHCMQswCQYDVQQG
EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q
UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0
aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN
AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDBemNDejWS/iB/hQVbp2Gd5eYWYb+z1RSPbY4RQHW/apL4auhig1FhCOrN+eN+32iYp3tm
K0kv/Rrhae9UzjFMzxc3QBcuj+H6kRudhawlrjeXMX7er9sqSIO0pDlaFvs7Kq0Lz7FFZL4e
whqdPfK5MROPp1ucUtI5mMkYE2y6Sll04UKoCWVK4bLsTkJGMp0lnpNRG2LaMKjZldJYe7ci
bkcTsnVPF4H4SVgwQbwkfw/wSS+HzOjtng3Nzz4z572WIMCwwJnfCVDJMXpdvssejkOaVl1/
+Ewqt80sjae67rD28v8sPAs7si+JIL5SYYqCw4djCSYfeMHO7R0qox3fAgMBAAGjggNuMIID
ajAMBgNVHRMEBTADAgEAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB
BQUHAwQwHQYDVR0OBBYEFFObPTX8kvCsGgtLWvPiSviKgJ51MIGoBgNVHSMEgaAwgZ2AFHuJ
nJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEPMIIBRwYDVR0g
BIIBPjCCATowggE2BgsrBgEEAYG1NwEBBTCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0
ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM
aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBv
bGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBj
BgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3Js
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAJNQdIoQBoFf8UslzTDD7ue89LppTEBJ
w5Za9ddTSfI8MEdomLK52FfLPu1JWWlzDZrwV/MHqTNqBHeXrjUxqnrERmKIXVZpIO7tEJia
cIGO2LYJoCMzXxOpIcAv2H9gVlAE0ibx3gOJ6XQGz7WUdOKouWUMf9aj1SCFJOChHTe6vSPl
rPjbJufQG7mwjpTrkwUos1/rznZWDCGCTUVLWiMN5XNzg8SMOurICxPborHlERiiX/ilwmL6
JBanoCQcyL45L40cFFF923FOWCXCHY0XAj/7MmVWpMl83tNRnXaYtukNJwM2C3rSEo3GTClU
IjB/0feH/9uWyMGPcF8WTxcwggc7MIIGI6ADAgECAgEpMA0GCSqGSIb3DQEBBQUAMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMDgwNzAyMjA0MzE4WhcNMDkwNzAy
MjA0MzE4WjCBwjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZE
ZW52ZXIxIjAgBgNVBAoTGVhNUFAgU3RhbmRhcmRzIEZvdW5kYXRpb24xLDAqBgNVBAsTI1N0
YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRlciBTYWlu
dC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXpjQ3o1kv4gf4UFW6dhneXmFmG/s9UUj22OEUB1v2qS
+GroYoNRYQjqzfnjft9omKd7ZitJL/0a4WnvVM4xTM8XN0AXLo/h+pEbnYWsJa43lzF+3q/b
KkiDtKQ5Whb7OyqtC8+xRWS+HsIanT3yuTETj6dbnFLSOZjJGBNsukpZdOFCqAllSuGy7E5C
RjKdJZ6TURti2jCo2ZXSWHu3Im5HE7J1TxeB+ElYMEG8JH8P8Ekvh8zo7Z4Nzc8+M+e9liDA
sMCZ3wlQyTF6Xb7LHo5DmlZdf/hMKrfNLI2nuu6w9vL/LDwLO7IviSC+UmGKgsOHYwkmH3jB
zu0dKqMd3wIDAQABo4IDbjCCA2owDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRTmz01/JLwrBoLS1rz4kr4ioCe
dTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD
ZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAQUwggElMC4GCCsG
AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIB
FihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8BggrBgEFBQcC
AjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0
aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRz
c2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0
dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au
c3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5jcnQwIwYDVR0S
BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCTUHSK
EAaBX/FLJc0ww+7nvPS6aUxAScOWWvXXU0nyPDBHaJiyudhXyz7tSVlpcw2a8FfzB6kzagR3
l641Map6xEZiiF1WaSDu7RCYmnCBjti2CaAjM18TqSHAL9h/YFZQBNIm8d4Diel0Bs+1lHTi
qLllDH/Wo9UghSTgoR03ur0j5az42ybn0Bu5sI6U65MFKLNf6852Vgwhgk1FS1ojDeVzc4PE
jDrqyAsT26Kx5REYol/4pcJi+iQWp6AkHMi+OS+NHBRRfdtxTlglwh2NFwI/+zJlVqTJfN7T
UZ12mLbpDScDNgt60hKNxkwpVCIwf9H3h//blsjBj3BfFk8XMIIH4jCCBcqgAwIBAgIBDzAN
BgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMzMyWhcNMTIx
MDIyMjEwMzMyWjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp
BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuaNJbhI+IMqUCKe9V4tk5V8i2K4/VpEcvnfQTtBR
z2JwLAvff48f4mzUcCHwKBYWXfiw7HHUUnJL8LhUs9GyoN8/vaO3MJVQAvQMDFnvCDNC8XPv
HrWMbF+FiGphvX4884uRgFuREis8yDd0sR0qZchglhcMf6YH9X+Mujvf8pvuH+s2g2D+gcdK
/kmiXK+nkhjZu19xMF9b+16UQWPmsNNfaO5O9ndCF/ddBflxrdDsDXTOtRX9xYk4nsXlGW1s
QhpuhmZfkkFRvcWFSIB0Gi16EBfoNsM65igm1XGYah/oa5UZw+j3wrhMl/wUej5QD0Q5UOn9
bt8KopPixeT9eQIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYD
VR0OBBYEFHuJnJKXJKGERwLLdPwu9KzcMuXzMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mH
MMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT
IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYB
BQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j
cnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy
bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1Ud
IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2Vy
dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh
cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENv
bW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVh
ZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0
YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0E
QxZBU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFp
bCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEFBQADggIBAFKXBA3bChUQsRQcXEpvvKDE036U
u322ZMVh8eXxw47wIGgUPqGNLZOMbWw+lcXh2I8SOt/oY/IyAp6nlVz3t+Abvl83pCJ9k5a5
zwkKGynUBdqedkIFLyMUlEXndI3AWggVdtg0imlKgzsw/08elUMu/M6W5V40R+zgCxP/h48y
VZrKXZwVFLUDi2ID6PduMZMUduVQ3YLRBObwF2v4NqAnmYctGRDuDW4CGsgGAiXCUQ89IXQ9
gIXnOuSsOiwdze1VxI4kUef1qCsB/0LXkczyWxQ3NbKJqwKY5tnMoPuZ25tUR3hSM/hsV5bk
az87b4TXG8tD7QI6sGNbcYuLFtEemST7mdg2df3c3JKBYcmYBcjl90hJDV1S5XY0853hSRZ1
Usw23O9tL6tfOI0e6WKCPfn+UCfemtIi8RABvEieWrgcFyP8NhZipsJnTLyfP9e/geLDAiEa
16w0Jdsc6VV4f0HJpOZ3/sPBxZqgExstTlAEG14GuwMkgFGmIb7xZOdLtGzuQ4lBsM6yTt06
8L2gthIuBBWgZiFYBu031OU2mmPSHCUgkOwBlGBN0RUkabCzqANw7MT+NmBEYEvzccNvfmKm
bT6DtkD2zaSO8Zx1QnzQWm8d6AyH+N/JxX7/LKcOQUKgUmxBdYsyQOe3hOuAsx57e5QdtDhQ
9dWr2KKcMYIDvTCCA7kCAQEwgZIwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD
QQIBKTAJBgUrDgMCGgUAoIIB/zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wOTAyMTcxNzA2NDlaMCMGCSqGSIb3DQEJBDEWBBQ+xnI/m6v3MvAjbrVtU8iv
scczuTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJKwYBBAGCNxAEMYGVMIGS
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwgaUGCyqGSIb3DQEJEAIL
MYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECASkwDQYJKoZIhvcN
AQEBBQAEggEAQjKeKQyom/ixUYuC/n3rvG2kWqsURd6KvhyxCSpGVrhWJBs/aQQO59EF69Ni
3nyqubQHpPYgd6frxt5ZWlyNGSNYY+gIJ2LzTzNHB8Z/0eZv9YKXzB5DctlRUj2kZN+9I9Er
ISdrR09dtTor+B7x1NKoah2Kyw9KbKfZHcxJvgoA7kHu2Hf0n6Sd6+fBOEPKyRXT/AXJvTld
4HnF78+UbAkvk1iv2WcQCe1uzwQRvlgqj1tsnPKJ+eR6TK9IiyRUQTL5ZbK5gPm0EKNWsVPA
zWL4Zl/XJNFieiFnraP1le2VfZEKQBoRjeOfF+vCeIZq4cqF7PGDDDYcr516FrP4ggAAAAAA
AA==
--------------ms020601090808020904060103--



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 n1HGpYJl095732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 09:51:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HGpYID095731; Tue, 17 Feb 2009 09:51:34 -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 n1HGpN8V095716 for <[e-mail]>; Tue, 17 Feb 2009 09:51:33 -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 n1HGpMAW003091 for <[e-mail]>; Tue, 17 Feb 2009 16:51:23 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 n1HGpMr2061016 for <[e-mail]>; Tue, 17 Feb 2009 09:51:22 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1HGgPPN001543; Tue, 17 Feb 2009 10:42:25 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1HGgOpt001542; Tue, 17 Feb 2009 10:42:24 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Feb 2009 10:42:24 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Mon, Feb 16, 2009 at 02:09:24PM -0800, Kurt Zeilenga wrote:
> On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:
> >I think SASL + TLS is the common case, thus to fail to describe SCRAM
> >SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> >position to take so as to simplify that document.  Thus anyone who'd
> >want to implement SCRAM sec layers would have to read the GS2 and
> >SCRAM-as-GSS-API-mech documents.
> 
> I think it would be good to have a GSSAPI-SCRAM I-D soon (before  
> IETF#74).

It'd be good, yes, but, does that have anything to do with this poll?



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 n1HGp65P095702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 09:51:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HGp6x4095701; Tue, 17 Feb 2009 09:51:06 -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 n1HGp5uR095695 for <[e-mail]>; Tue, 17 Feb 2009 09:51:05 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 16:51:04 +0000
Cc: Arnt Gulbrandsen <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: SASL interop event  (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
Date: Tue, 17 Feb 2009 08:51:01 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 17, 2009, at 2:40 AM, Alexey Melnikov wrote:

>
> Arnt Gulbrandsen wrote:
>
>> Alexey (http://tools.ietf.org/html/draft-ietf-sasl-digest-to- 
>> historic) made me think there are _many_ digest-md5 implementations  
>> out there. Fifty or a hundred seem a more reasonable estimates than  
>> ten. If the number were ten or twenty, it would have been practical  
>> to gather a good fraction of the implentors for an interop event.

During at least one of the LDAP interop events, we specifically tested  
SASL/DIGEST-MD5 interoperability.  It didn't go well.

-- 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 n1HGfvw3095285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 09:41:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HGfvJA095284; Tue, 17 Feb 2009 09:41:57 -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 n1HGfkDc095276 for <[e-mail]>; Tue, 17 Feb 2009 09:41:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.146] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 17 Feb 2009 16:41:44 +0000
Cc: SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 17 Feb 2009 08:41:40 -0800
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

The chairs plan on making some evaluation of this question within the  
next few days.

If you haven't commented already, please now state your opinion.

-- Kurt

On Feb 5, 2009, at 1:14 PM, Alexey Melnikov wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice  
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short  
> explanation of why) to the mailing list, or say if you need more  
> information.
>
> I would like to get all answers before February 19th, please.
>
> Regards,
> Alexey
>



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 n1HAeSRJ075408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 03:40:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1HAeS3D075407; Tue, 17 Feb 2009 03:40:28 -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 n1HAeHJ4075393 for <[e-mail]>; Tue, 17 Feb 2009 03:40:28 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.192] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 17 Feb 2009 10:40:16 +0000
Message-ID: <[e-mail]>
Date: Tue, 17 Feb 2009 10:40:00 +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: Arnt Gulbrandsen <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: SASL interop event (was Re: Poll: pure SCRAM versa SCRAM-as-GS2)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar>
In-Reply-To: <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar>
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>

Arnt Gulbrandsen wrote:

> Alexey (http://tools.ietf.org/html/draft-ietf-sasl-digest-to-historic) 
> made me think there are _many_ digest-md5 implementations out there. 
> Fifty or a hundred seem a more reasonable estimates than ten. If the 
> number were ten or twenty, it would have been practical to gather a 
> good fraction of the implentors for an interop event.
>
> The number of SASL implementations can't be any smaller.

I think implementors of major open source SASL libraries are subscribed 
to this mailing list.
Getting a hold of other implementors might not be trivial - many of them 
don't participate in this mailing list and are not known to me personally.



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 n1H9ZA83071110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 02:35:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1H9ZAZn071109; Tue, 17 Feb 2009 02:35:10 -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 n1H9YwfT071085 for <[e-mail]>; Tue, 17 Feb 2009 02:35:10 -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 62B074AC71; Tue, 17 Feb 2009 10:34:57 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1234863296-9030-1/6/160 for [e-mail]; Tue, 17 Feb 2009 10:34:56 +0100
Message-Id: <AV+E/UMw5DFm8Utl/evaeQ.md5@lochnagar>
Date: Tue, 17 Feb 2009 10:36:07 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Alexey (http://tools.ietf.org/html/draft-ietf-sasl-digest-to-historic) 
made me think there are _many_ digest-md5 implementations out there. 
Fifty or a hundred seem a more reasonable estimates than ten. If the 
number were ten or twenty, it would have been practical to gather a 
good fraction of the implentors for an interop event.

The number of SASL implementations can't be any smaller.

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 n1H6FC56064093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 23:15:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1H6FCJN064092; Mon, 16 Feb 2009 23:15:12 -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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1H6F0Ll064076 for <[e-mail]>; Mon, 16 Feb 2009 23:15:10 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 16 Feb 2009 22:04:24 -0800 (PST)
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]; Mon, 16 Feb 2009 17:35:30 -0800 (PST)
Date: Mon, 16 Feb 2009 17:14:54 -0800 (PST)
From: [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-reply-to: "Your message dated Mon, 16 Feb 2009 10:01:38 -0800" <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Hallvard B Furuseth <[e-mail]>, Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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 Feb 16, 2009, at 9:26 AM, Hallvard B Furuseth wrote:

> > One reality check: I have no idea what kind of SASL implementations
> > are
> > out there.  Are there implementations that do not support GS2/GSS?

> Yes.  For instance, it's fairly common to implement a basic SASL
> implementation when one only requires simple SASL mechanisms (e.g.,
> EXTERNAL, PLAIN, CRAM-MD5).

Over the years we've done several separate implementations of SASL, both server
and client, supporting a variety of SASL mechanisms: EXTERNAL, PLAIN, LOGIN,
CRAM-MD5, DIGEST-MD5, etc. But none of them have ever supported GS2/GSS, either
through our own code or through interfacing with public libraries.

Frankly, unless the quality of the publicly available code for GS2/GSS has
improved by at least an order of magnitude since the last time I looked at it,
there's no chance we'll ever support GS2/GSS directly through publicly
available code. Putting that code in the middle of a complex, multithreaded
client or server seems like a sure-fire recipe for disaster. If we absolutely
had to have support for this we'd do it by talking to a separate, single
threaded authentication server process using some sort of simple protocol.

As for writing our own, the last time I looked into this I'm afraid I could not
make head nor tails of the specifications. Now, this was some time ago and the
specifications may have improved since then. Or alternately, it could be due to
my own stupidity, but as a point of comparison I'm someone who was able to code
a full implementation of X.400-1988 and the specifications for that were IMO
plenty clear enough to implement from.

> [I've done this myself a couple of
> times.]  I would hope that SCRAM would have similar complexity to CRAM-
> MD5, and hence implementable quite independently of so-called "SASL
> libraries" and GS2 and GSS-API frameworks.

Indeed. Not having to use a library is a pretty significant win in a lot of
cases. That's another reason why I'm strongly in favor of keeping the
complexity in SCRAM to an absolute minimum.

				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 n1GM9UOQ048087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 15:09:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GM9Udf048086; Mon, 16 Feb 2009 15:09:30 -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 n1GM9TG2048080 for <[e-mail]>; Mon, 16 Feb 2009 15:09:29 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Mon, 16 Feb 2009 22:09:28 +0000
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 14:09:24 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:

> I think SASL + TLS is the common case, thus to fail to describe SCRAM
> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> position to take so as to simplify that document.  Thus anyone who'd
> want to implement SCRAM sec layers would have to read the GS2 and
> SCRAM-as-GSS-API-mech documents.

I think it would be good to have a GSSAPI-SCRAM I-D soon (before  
IETF#74).

-- 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 n1GM3B0x047832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 15:03:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GM3B87047831; Mon, 16 Feb 2009 15:03:11 -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 n1GM2xTN047823 for <[e-mail]>; Mon, 16 Feb 2009 15:03:10 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.135] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Mon, 16 Feb 2009 22:02:58 +0000
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 14:02:54 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 16, 2009, at 1:32 PM, Nicolas Williams wrote:

>
> On Mon, Feb 16, 2009 at 12:59:44PM -0800, Kurt Zeilenga wrote:
>> On Feb 16, 2009, at 11:59 AM, Alexey Melnikov wrote:
>>> Kurt Zeilenga wrote:
>>>> More precisely I think, the GS2-SCRAM I-D doesn't discuss how to
>>>> implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security
>>>> layer for the GSS-API SCRAM mechanism.
>>>
>>> No, it is quite explicit about that: GS2 security layer is
>>> negotiated off.
>
> When channel binding succeeds.
>
>> My point is that SASL-GS2-GSS-SCRAM would be capable of supporting
>> SASL security layers but the GS2-SCRAM I-D fails to detail how to
>> implement them.
>>
>> My view GS2-SCRAM I-D as being incomplete.   It should either detail
>> how to offer the GS2+GSSAPI+SCRAM layers, or it should detail why it
>> doesn't.
>
> I'm not sure.
>
> I think SASL + TLS is the common case, thus to fail to describe SCRAM
> SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
> position to take so as to simplify that document.  Thus anyone who'd
> want to implement SCRAM sec layers would have to read the GS2 and
> SCRAM-as-GSS-API-mech documents.


The GS2-SCRAM I-D currently has this note:
     <<For simplicity, this family of mechanism does not presently  
include negotiation of a security layer. It is intended to be used  
with an external security layer such as that provided by TLS or SSH.>>
which is seems incorrect to me.  The GS2 family of mechanisms do  
support negotiation of a (SASL) layer, and that includes when the GSS- 
API SCRAM mechanism is in use via GS2.  This I-D should, if it's not  
going to provide a description of how to implement those layers  
without G2 and GSS-API, should say something like:
     While the GS2 family of mechanisms, including when used with the  
GSS-API SCRAM mechanism, do offer SASL security layers, this document  
does not discuss how to implement them.
Then a rationale for making this choice should be offered, possibly in  
the Security Considerations section of the I-D.
-- 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 n1GLfosS046957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 14:41:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GLfowA046956; Mon, 16 Feb 2009 14:41: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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1GLfeU1046932 for <[e-mail]>; Mon, 16 Feb 2009 14:41:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1GLfdo9005870 for <[e-mail]>; Mon, 16 Feb 2009 21:41:40 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 n1GLfdC3026426 for <[e-mail]>; Mon, 16 Feb 2009 14:41:39 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1GLWgrf001126; Mon, 16 Feb 2009 15:32:42 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1GLWfLh001124; Mon, 16 Feb 2009 15:32:41 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 16 Feb 2009 15:32:41 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[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 Mon, Feb 16, 2009 at 12:59:44PM -0800, Kurt Zeilenga wrote:
> On Feb 16, 2009, at 11:59 AM, Alexey Melnikov wrote:
> >Kurt Zeilenga wrote:
> >>More precisely I think, the GS2-SCRAM I-D doesn't discuss how to   
> >>implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security   
> >>layer for the GSS-API SCRAM mechanism.
> >
> >No, it is quite explicit about that: GS2 security layer is  
> >negotiated off.

When channel binding succeeds.

> My point is that SASL-GS2-GSS-SCRAM would be capable of supporting  
> SASL security layers but the GS2-SCRAM I-D fails to detail how to  
> implement them.
> 
> My view GS2-SCRAM I-D as being incomplete.   It should either detail  
> how to offer the GS2+GSSAPI+SCRAM layers, or it should detail why it  
> doesn't.

I'm not sure.

I think SASL + TLS is the common case, thus to fail to describe SCRAM
SASL sec layers in the SCRAM-GS2-as-pure-SASL doc is a reasonable
position to take so as to simplify that document.  Thus anyone who'd
want to implement SCRAM sec layers would have to read the GS2 and
SCRAM-as-GSS-API-mech documents.

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 n1GKxpxA045079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 13:59:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GKxpmP045078; Mon, 16 Feb 2009 13:59:51 -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 n1GKxnIg045072 for <[e-mail]>; Mon, 16 Feb 2009 13:59:50 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Mon, 16 Feb 2009 20:59:48 +0000
X-SMTP-Protocol-Errors: NORDNS
Cc: Hallvard B Furuseth <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 12:59:44 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 16, 2009, at 11:59 AM, Alexey Melnikov wrote:

>
> Kurt Zeilenga wrote:
>
>> On Feb 16, 2009, at 11:42 AM, Alexey Melnikov wrote:
>>
>>>> Or if it's too weak to be called that, should it be
>>>> strengthened so it can be considered one?  The hashed  
>>>> AuthMessage  in the
>>>> ServerSignature would be the messages from the entire exchange,  
>>>> not  just
>>>> up to the final client message.
>>>
>>> Neither version of SCRAM provide any SASL security layer at the   
>>> moment.
>>
>> More precisely I think, the GS2-SCRAM I-D doesn't discuss how to   
>> implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security   
>> layer for the GSS-API SCRAM mechanism.
>
> No, it is quite explicit about that: GS2 security layer is  
> negotiated off.

My point is that SASL-GS2-GSS-SCRAM would be capable of supporting  
SASL security layers but the GS2-SCRAM I-D fails to detail how to  
implement them.

My view GS2-SCRAM I-D as being incomplete.   It should either detail  
how to offer the GS2+GSSAPI+SCRAM layers, or it should detail why it  
doesn't.

-- 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 n1GJxbiZ042663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 12:59:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GJxbH7042662; Mon, 16 Feb 2009 12:59:37 -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 n1GJxaDZ042656 for <[e-mail]>; Mon, 16 Feb 2009 12:59:37 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.146.253] (92.40.146.253.sub.mbb.three.co.uk [92.40.146.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 16 Feb 2009 19:59:34 +0000
Message-ID: <[e-mail]>
Date: Mon, 16 Feb 2009 19:59:18 +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: Kurt Zeilenga <[e-mail]>
CC: Hallvard B Furuseth <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; 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>

Kurt Zeilenga wrote:

> On Feb 16, 2009, at 11:42 AM, Alexey Melnikov wrote:
>
>>> Or if it's too weak to be called that, should it be
>>> strengthened so it can be considered one?  The hashed AuthMessage  
>>> in the
>>> ServerSignature would be the messages from the entire exchange, not  
>>> just
>>> up to the final client message.
>>
>> Neither version of SCRAM provide any SASL security layer at the  moment.
>
> More precisely I think, the GS2-SCRAM I-D doesn't discuss how to  
> implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security  
> layer for the GSS-API SCRAM mechanism.

No, it is quite explicit about that: GS2 security layer is negotiated off.



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 n1GJw297042597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 12:58:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GJw2SL042596; Mon, 16 Feb 2009 12:58:02 -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 n1GJw1dM042590 for <[e-mail]>; Mon, 16 Feb 2009 12:58:01 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Mon, 16 Feb 2009 19:58:00 +0000
Cc: Hallvard B Furuseth <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 11:57:55 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 16, 2009, at 11:42 AM, Alexey Melnikov wrote:

>>
>> Or if it's too weak to be called that, should it be
>> strengthened so it can be considered one?  The hashed AuthMessage  
>> in the
>> ServerSignature would be the messages from the entire exchange, not  
>> just
>> up to the final client message.
>>
> Neither version of SCRAM provide any SASL security layer at the  
> moment.

More precisely I think, the GS2-SCRAM I-D doesn't discuss how to  
implement (without implementing GS2+GSSAPI+SCRAM) the GS2 security  
layer for the GSS-API SCRAM mechanism.

-- 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 n1GJm5ua042207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 12:48:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GJm52N042206; Mon, 16 Feb 2009 12:48:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1GJm3ib042200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Feb 2009 12:48:04 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LZ9Ri-0003kZ-6v; Mon, 16 Feb 2009 20:48:02 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx6.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LZ9Rh-0005DF-Rf; Mon, 16 Feb 2009 20:48:02 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LZ9Rh-0003Vu-QF; Mon, 16 Feb 2009 20:48:01 +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: Mon, 16 Feb 2009 20:48:01 +0100
To: Alexey Melnikov <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Kurt Zeilenga <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 6B241F65A4BF7715850064AB8785D350D7B02F48
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1386 max/h 8 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>

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>> Is the HMAC(<StoredKey/ServerKey>, AuthMessage) in SCRAM an integrity
>> protection layer?

I should have asked, did it double as a security layer.  Anyway,

> No:
>(...)
> Actually no, I moved auhorization identity and channel binding out of 
> AuthMessage, because they are transported by the GS2 itself. They are a 
> part of the stuff signed with GSS_Wrap.

Duh, of course.  Part of the undescribed gs2 semantics I'd just been
talking about.  Never mind.

-- 
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 n1GJgcn4042023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 12:42:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GJgcde042022; Mon, 16 Feb 2009 12:42:38 -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 n1GJgavu042016 for <[e-mail]>; Mon, 16 Feb 2009 12:42:37 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.146.253] (92.40.146.253.sub.mbb.three.co.uk [92.40.146.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 16 Feb 2009 19:42:33 +0000
Message-ID: <[e-mail]>
Date: Mon, 16 Feb 2009 19:42:17 +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: Hallvard B Furuseth <[e-mail]>
CC: Nicolas Williams <[e-mail]>, Kurt Zeilenga <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; 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>

Hallvard B Furuseth wrote:

>Nicolas Williams writes:
>  
>
>>Given that SASL-GS2 security layers would be optional, but also that the
>>basis for an integrity protection layer being part of the SCRAM
>>internals for channel binding, IMO:
>>
>> - the spec should describe the integrity protection security layer
>> - the spec need not describe a privacy protection (encryption) security
>>   layer, which can then be provided by a separate I-D.
>>    
>>
>Is the HMAC(<StoredKey/ServerKey>, AuthMessage) in SCRAM an integrity
>protection layer?
>
No:

    ClientSignature := HMAC(StoredKey, AuthMessage)
    ServerSignature := HMAC(ServerKey, AuthMessage)

They are used by the client/server side to confirm that they know 
password (or some information derived from it) and to make sure that the 
AuthMessage wasn't tempered with.

>Or if it's too weak to be called that, should it be
>strengthened so it can be considered one?  The hashed AuthMessage in the
>ServerSignature would be the messages from the entire exchange, not just
>up to the final client message.
>  
>
Neither version of SCRAM provide any SASL security layer at the moment.

>SCRAM-GS2 moved channel bindings and authzid out of AuthMessage,
>presumably due to this text in GS2-10:
>  
>
Actually no, I moved auhorization identity and channel binding out of 
AuthMessage, because they are transported by the GS2 itself. They are a 
part of the stuff signed with GSS_Wrap.

>>10.  Non-integrity capable GSS-API mechanisms
>>
>>  Channel bindings and security layers MUST NOT be negotiated when the
>>  GSS-API mechanism do not support integrity.  It should also be
>>  understood that the authorization identity is not integrity
>>  protected.
>>    
>>
>Which makes me curious - does GSS-API not allow for a mechanism which
>supports channel bindings but not its own integrity protection layer?
>
>Or is it just that GSS-API expects more of integrity protection than
>SASL does, so one can't necessarily call a SASL protection layer a
>GSS-API protection layer?  I notice this GS2 section mentions
>"per-message" integrity protection in some but not all places, for
>example.
>  
>



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 n1GJXnvq041440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 12:33:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GJXnW0041439; Mon, 16 Feb 2009 12:33:49 -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 n1GJXm6N041433 for <[e-mail]>; Mon, 16 Feb 2009 12:33:49 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.146.253] (92.40.146.253.sub.mbb.three.co.uk [92.40.146.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SZm=[e-mail]>; Mon, 16 Feb 2009 19:33:46 +0000
Message-ID: <[e-mail]>
Date: Mon, 16 Feb 2009 19:33:27 +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: Hallvard B Furuseth <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Hallvard B Furuseth wrote:

>Kurt Zeilenga writes:
>  
>
>One reality check: I have no idea what kind of SASL implementations are
>out there.  Are there implementations that do not support GS2/GSS?
>
I can't only talk for one implementation: CMU SASL doesn't provide 
GSS-API interface, it is a pure SASL implementation.

>Or is the technical complexity a storm in a teacup because implementations
>will have GS2 for the sake of Kerberos?
>  
>



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 n1GIoAam039631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 11:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GIoAGH039630; Mon, 16 Feb 2009 11:50:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1GInw4E039603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Feb 2009 11:50:09 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LZ8XU-0003vj-GX; Mon, 16 Feb 2009 19:49:56 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx1.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LZ8XU-0002kh-8h; Mon, 16 Feb 2009 19:49:56 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LZ8XU-0003OK-7M; Mon, 16 Feb 2009 19:49:56 +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: Mon, 16 Feb 2009 19:49:56 +0100
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
References: <[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 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: B66EE1E1832A2C52011E2792DAE901F16EDFAA1C
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1385 max/h 8 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:
> Given that SASL-GS2 security layers would be optional, but also that the
> basis for an integrity protection layer being part of the SCRAM
> internals for channel binding, IMO:
> 
>  - the spec should describe the integrity protection security layer
>  - the spec need not describe a privacy protection (encryption) security
>    layer, which can then be provided by a separate I-D.

Is the HMAC(<StoredKey/ServerKey>, AuthMessage) in SCRAM an integrity
protection layer?  Or if it's too weak to be called that, should it be
strengthened so it can be considered one?  The hashed AuthMessage in the
ServerSignature would be the messages from the entire exchange, not just
up to the final client message.


SCRAM-GS2 moved channel bindings and authzid out of AuthMessage,
presumably due to this text in GS2-10:

> 10.  Non-integrity capable GSS-API mechanisms
>
>   Channel bindings and security layers MUST NOT be negotiated when the
>   GSS-API mechanism do not support integrity.  It should also be
>   understood that the authorization identity is not integrity
>   protected.

Which makes me curious - does GSS-API not allow for a mechanism which
supports channel bindings but not its own integrity protection layer?

Or is it just that GSS-API expects more of integrity protection than
SASL does, so one can't necessarily call a SASL protection layer a
GSS-API protection layer?  I notice this GS2 section mentions
"per-message" integrity protection in some but not all places, for
example.

-- 
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 n1GI1up0037710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 11:01:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GI1uD7037709; Mon, 16 Feb 2009 11:01:56 -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 n1GI1ivw037691 for <[e-mail]>; Mon, 16 Feb 2009 11:01:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Mon, 16 Feb 2009 18:01:42 +0000
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 16 Feb 2009 10:01:38 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 16, 2009, at 9:26 AM, Hallvard B Furuseth wrote:

> One reality check: I have no idea what kind of SASL implementations  
> are
> out there.  Are there implementations that do not support GS2/GSS?

Yes.  For instance, it's fairly common to implement a basic SASL  
implementation when one only requires simple SASL mechanisms (e.g.,  
EXTERNAL, PLAIN, CRAM-MD5).  [I've done this myself a couple of  
times.]  I would hope that SCRAM would have similar complexity to CRAM- 
MD5, and hence implementable quite independently of so-called "SASL  
libraries" and GS2 and GSS-API frameworks.

-- 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 n1GHQxqo036031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2009 10:26:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1GHQx0q036030; Mon, 16 Feb 2009 10:26:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1GHQjE4036013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 16 Feb 2009 10:26:57 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LZ7Ex-0008Lw-PP; Mon, 16 Feb 2009 18:26:43 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx4.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LZ7Ex-0006sh-Gj; Mon, 16 Feb 2009 18:26:43 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LZ7Ex-0003F3-1x; Mon, 16 Feb 2009 18:26:43 +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: Mon, 16 Feb 2009 18:26:43 +0100
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 0CCE67125F9E435A660403A888A365758F0C9DEC
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1384 max/h 8 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>

Kurt Zeilenga writes:
> Draft-newman-auth-scram-gs2-00.txt contains a normative reference to
> draft-ietf-sasl-gs2-10.txt.  This implies an implementor must read and
> understand draft-ietf-sasl-gs2-10.txt, as well as elements of its
> normative references, in order to implement the protocol.  (I doubt
> this normative reference can be downgraded.)

Yes, looks like it.  That's the main problem for a non-GSS person like
me.  There might be only a small amount of GS2 semanics which needs to
be implemented, but if so it looks like I'd still have to read and
understand GS2 and GSS-API to figure that out.  OK, so I've begun to
read up on GS2 anyway, but still...

For SCRAM-GS2 to be pure-SASL friendly, what one needs to understand
about the GS2 part needs to be collected in one place.  Either in
SCRAM-GS2 or in a section of GS2, so SCRAM-GS2 can refer to just that
section.  Then the complexity argument about SCRAM-GS2 is reduced to its
technical complexity, which I don't know yet.

I would oppose a SCRAM-GS2 document which didn't do that.  OTOH it's
fine by me if the current draft is just a draft for a draft which will,
to have a poll about among those who know what the final document set
would look like.

BTW, if the GS2 folk write up that and present it for a new poll or
whatever, I'm not suggesting to put a lot of work into getting the
details right at first try.  After all comments here suggest it may
well be rejected anyway.


Regarding where to put the GS2 part, I'm staying with my original
comments.  Maybe I had picked up a bit more about GS2 than I realized.
GS2 seems to me the natural place for the normative part, maybe copied
to a SCRAM-GS2 informative section.  Of course it would be a bit better
to know what it would look like before saying that:-)

Actually complexity might be an argument _for_ placing it in GS2.
Otherwise future mechanisms that try to bridge pure SASL and GS2 must
copy or re-do that work from SCRAM.  The trick would be to make it loose
enough that it's not another layer SCRAM will exist inside, but just
some stuff SCRAM makes use of like it makes use of Base64 and HMAC.


Since SCRAM-GS2 effectively will have 2 specs which are supposed to
interoprate, I suggest to stick to the old IETF "2 implementations" rule
on this one.  Set up one pure-SASL and one GSS-API version of SCRAM-GS2
and let us see them interoperate.  If the author of the pure-SASL mech
doesn't know GS2, so much the better.


One reality check: I have no idea what kind of SASL implementations are
out there.  Are there implementations that do not support GS2/GSS?  Or
is the technical complexity a storm in a teacup because implementations
will have GS2 for the sake of Kerberos?


-- 
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 n1FMXiCQ088389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2009 15:33:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1FMXiJS088388; Sun, 15 Feb 2009 15:33:44 -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 n1FMXXBx088352 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Sun, 15 Feb 2009 15:33:44 -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 n1FMXXTa004244 for <[e-mail]>; Sun, 15 Feb 2009 22:33:33 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 n1FMXWIo040111 for <[e-mail]>; Sun, 15 Feb 2009 15:33:33 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1FMOeW0000650; Sun, 15 Feb 2009 16:24:40 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1FMOcnR000649; Sun, 15 Feb 2009 16:24:38 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sun, 15 Feb 2009 16:24:38 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Paul Leach <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[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 Sun, Feb 15, 2009 at 09:01:19PM +0000, Alexey Melnikov wrote:
> Paul Leach wrote:
> 
> >BTW: has anyone thought about use of SCRAM with HTTP?
> > 
> >
> Yes, but not in details. The protocol should be easily extensible to HTTP.

You may have missed the point that Paul was, I think, trying to make.

Given HTTP/Negotiate (and the new version of it) a GSS-API mechanism
would fit right in in HTTP.  Thus SCRAM-as-GS2 is ideal for HTTP, but
SCRAM-as-not-GS2 is not as that would require either adapting it to
HTTP, to the GSS-API, or extending HTTP to support SASL.

The re-use aspect of SCRAM-as-GS2 is not a silly whim, or idealism -- it
will really help those of us who implement both, GSS-API application
protocols, such as DNS (see GSS-TSIG), CIFS/SMB, NFS, SSHv2, FTP, HTTP,
and so on, and SASL apps, such as LDAP, IMAP, SMTP, etcetera.

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 n1FL2D9B085666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2009 14:02:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1FL2DP0085665; Sun, 15 Feb 2009 14:02:13 -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 n1FL21Le085659 for <[e-mail]>; Sun, 15 Feb 2009 14:02:12 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.219.94] (92.40.219.94.sub.mbb.three.co.uk [92.40.219.94])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SZiCxwB0lH3=@rufus.isode.com>; Sun, 15 Feb 2009 21:02:00 +0000
Message-ID: <[e-mail]>
Date: Sun, 15 Feb 2009 21:01:19 +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: Paul Leach <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <87fxilqgiy.fsf@mocca <[e-mail]> <[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>

Paul Leach wrote:

>BTW: has anyone thought about use of SCRAM with HTTP?
>  
>
Yes, but not in details. The protocol should be easily extensible to HTTP.



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 n1FHCaf6078570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2009 10:12:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1FHCajJ078569; Sun, 15 Feb 2009 10:12:36 -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 n1FHCOB3078557 for <[e-mail]>; Sun, 15 Feb 2009 10:12:35 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.219.94] (92.40.219.94.sub.mbb.three.co.uk [92.40.219.94])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 15 Feb 2009 17:12:23 +0000
Message-ID: <[e-mail]>
Date: Sun, 15 Feb 2009 17:11:50 +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
MIME-Version: 1.0
To: SASL WG <[e-mail]>
Subject: [Fwd: I-D Action:draft-newman-auth-scram-09.txt]
Content-Type: multipart/mixed; boundary="------------030907080205080004000202"
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>

--------------030907080205080004000202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I've updated the pure-SCRAM document to match more closely the GS2 
variant. In particular I fixed ABNF for channel-binding and moved SASL 
authorization identity to the second message from the client.


--------------030907080205080004000202
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-09.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-09.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine (Isode M-Box/14.3v2) with LMTP; Sun, 15 Feb 2009 14:15:32 +0000 (GMT)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Sun, 15 Feb 2009 14:15:32 +0000
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8F3873A6992;
	Sun, 15 Feb 2009 06:15:02 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0)
	id 7EB633A6955; Sun, 15 Feb 2009 06:15:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-newman-auth-scram-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun, 15 Feb 2009 06:15:01 -0800 (PST)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-09.txt
	Pages           : 18
	Date            : 2009-02-15

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------030907080205080004000202--



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 n1FDYvH9071171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Feb 2009 06:34:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1FDYvvF071170; Sun, 15 Feb 2009 06:34:57 -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 n1FDYjjO071162 for <[e-mail]>; Sun, 15 Feb 2009 06:34:56 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.219.94] (92.40.219.94.sub.mbb.three.co.uk [92.40.219.94])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 15 Feb 2009 13:34:43 +0000
Message-ID: <[e-mail]>
Date: Sun, 15 Feb 2009 13:34:21 +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: Hallvard B Furuseth <[e-mail]>
CC: [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Hallvard B Furuseth wrote:

>Alexey Melnikov wrote:
>  
>
>>Hallvard B Furuseth wrote:
>>
>>>Also, how does an iteration count of more than 1 help on a site where
>>>passwords are stored in several forms anyway, maybe including salted MD5
>>>for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)
>>>      
>>>
>>My understanding is that one can read values from hashed password files
>>and use them to implement server side SCRAM.
>>There is no requirement that SCRAM specific hash be stored in such files.
>>    
>>
>That sounds strange, unless you are talking about a weakness which can
>be attacked.
>
>The password-file secret would be
>  salt, Hash(salt || password)
>while even with iteration count 0, SCRAM SaltedPassword is
>  Hash((password XOR opad) || Hash((password XOR ipad) || salt || INT(1)))
>
You are right.
I've checked earlier versions of both SCRAM and HEXA and neither of them 
mentioned use in Unix hashed password databases.
So this was just my wishful thinking.

>In any case, if there is a mapping MD5 crypt -> SCRAM crypt, that just
>makes the iteration count less useful as far as I can see.
>  
>



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 n1D5dUtc050856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 22:39:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1D5dUIm050855; Thu, 12 Feb 2009 22:39:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1D5dInC050843 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 12 Feb 2009 22:39:28 -0700 (MST) (envelope-from [e-mail])
Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 12 Feb 2009 21:39:11 -0800
Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.2.99.4; Thu, 12 Feb 2009 21:39:10 -0800
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Thu, 12 Feb 2009 21:39:10 -0800
From: Paul Leach <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Date: Thu, 12 Feb 2009 21:39:10 -0800
Subject: RE: Poll: pure SCRAM versa SCRAM-as-GS2
Thread-Topic: Poll: pure SCRAM versa SCRAM-as-GS2
Thread-Index: AcmMawbbjLDCor5vSPCc9v5VrbftXQBMevkg
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <87fxilqgiy.fsf@mocca <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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>

I've only been lurking here, and can't claim to understand everything very =
deeply, but I can state pretty positively that if SCRAM becomes the mandato=
ry-to-implement auth mechanism for a bunch of protocols, then we're very mu=
ch prefer to implement it via the GS2 route, and not have to do it twice.

BTW: has anyone thought about use of SCRAM with HTTP?




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 n1CNThoS036748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 16:29:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1CNThK1036747; Thu, 12 Feb 2009 16:29:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1CNTTpw036735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Feb 2009 16:29:41 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LXkzn-000838-9Q; Fri, 13 Feb 2009 00:29:27 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx4.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LXkzn-0000fO-38; Fri, 13 Feb 2009 00:29:27 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LXkzm-0000r5-NO; Fri, 13 Feb 2009 00:29:26 +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: Fri, 13 Feb 2009 00:29:26 +0100
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 92FAA1A48C36537563023045D6B652015458D7DD
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 1382 max/h 8 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, Feb 10, 2009 at 10:17:35PM +0100, Hallvard B Furuseth wrote:
>(...snip...)
>
>> Is there a summary somewhere of why things are done this way?
> There is above.  If the I-Ds don't capture this, they probably should.

Thank you, nice summary.  Yes, the I-Ds should definitely capture this.

-- 
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 n1CFCInC014277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 08:12:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1CFCItM014276; Thu, 12 Feb 2009 08:12:18 -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 n1CFC6F9014261 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 12 Feb 2009 08:12:17 -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 n1CFC5nK017651 for <[e-mail]>; Thu, 12 Feb 2009 15:12:06 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 n1CFC59M028173 for <[e-mail]>; Thu, 12 Feb 2009 08:12:05 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1CF3DrA018088; Thu, 12 Feb 2009 09:03:13 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1CF3DSA018087; Thu, 12 Feb 2009 09:03:13 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 12 Feb 2009 09:03:13 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, Simon Josefsson <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[e-mail]> <[e-mail]> <lu8I0w0+TyOhQ3qrWyFgRA.md5@lochnagar> <[e-mail]> <gudAk/n8QRH8aZ7NVpJGVQ.md5@lochnagar>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <gudAk/n8QRH8aZ7NVpJGVQ.md5@lochnagar>
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, Feb 12, 2009 at 04:00:33PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >We're trying to avoid having to implement SCRAM for SASL and SCRAM for 
> >GSS-API, but rather, implement one or the other, but not both.
> 
> Oh... and the big problem is that people clearly want one of those, but 
> noone seems to want the other very much, so what's the point?

The point is to make it so you, a pure SASL implementor, can implement a
pure-SASL SCRAM that happens to interop with the SCRAM implemented by a
SASL/GS2 implementor as a GSS-API 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 n1CExXBI013403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 07:59:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1CExX1Y013402; Thu, 12 Feb 2009 07:59:33 -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 n1CExWxH013387 for <[e-mail]>; Thu, 12 Feb 2009 07:59:32 -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 577A64AC5A; Thu, 12 Feb 2009 15:59:31 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1234450770-9030-1/6/145 (5 recipients); Thu, 12 Feb 2009 15:59:30 +0100
Message-Id: <gudAk/n8QRH8aZ7NVpJGVQ.md5@lochnagar>
Date: Thu, 12 Feb 2009 16:00:33 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, Simon Josefsson <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[e-mail]> <[e-mail]> <lu8I0w0+TyOhQ3qrWyFgRA.md5@lochnagar> <[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>

Nicolas Williams writes:
> We're trying to avoid having to implement SCRAM for SASL and SCRAM for 
> GSS-API, but rather, implement one or the other, but not both.

Oh... and the big problem is that people clearly want one of those, but 
noone seems to want the other very much, so what's the point?

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 n1CEVb7O011607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 07:31:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1CEVbud011606; Thu, 12 Feb 2009 07:31:37 -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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1CEVbQR011600 for <[e-mail]>; Thu, 12 Feb 2009 07:31:37 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1CEVbj0014786 for <[e-mail]>; Thu, 12 Feb 2009 14:31:37 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 n1CEVaxL000075 for <[e-mail]>; Thu, 12 Feb 2009 07:31:36 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1CEMj7l017907; Thu, 12 Feb 2009 08:22:45 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1CEMj6s017906; Thu, 12 Feb 2009 08:22:45 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 12 Feb 2009 08:22:45 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[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, Feb 12, 2009 at 11:23:37AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
> > only for the krb5 mech, and will likely never be used again: the
> > precedent will be clear that no one will care to build mechanisms for
> > one framework and then have then automatically available for the other,
> > thus it will never be done for any other mechanisms.
> 
> I'm less convinced of that.  I want to see a password-based GSS-API
> mechanism, which would be possible to use in SASL via GS2, so there will
> be at least one.  I agree pure-SASL-SCRAM would set a precedent, but I
> don't think it will prevent future work towards merging the GSS-API and
> SASL frameworks.

Why have multiple equivalent password-based mechanisms for SASL?

No, if SCRAM-as-not-GS2 happens then it'd be a safe bet that GS2 will
only ever be used for Kerberos V.



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 n1CEUCa8011514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 07:30:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1CEUCJp011513; Thu, 12 Feb 2009 07:30:12 -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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1CETxPu011374 for <[e-mail]>; Thu, 12 Feb 2009 07:30:09 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1CETxnd014261 for <[e-mail]>; Thu, 12 Feb 2009 14:29:59 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 n1CETwiZ064203 for <[e-mail]>; Thu, 12 Feb 2009 07:29:58 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1CEL3Ih017900; Thu, 12 Feb 2009 08:21:05 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1CEKhO5017897; Thu, 12 Feb 2009 08:20:43 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 12 Feb 2009 08:20:43 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, Simon Josefsson <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[e-mail]> <[e-mail]> <lu8I0w0+TyOhQ3qrWyFgRA.md5@lochnagar>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <lu8I0w0+TyOhQ3qrWyFgRA.md5@lochnagar>
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, Feb 12, 2009 at 02:03:29PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >If we drop SCRAM-as-GS2 then GS2 will be useful only for the krb5 
> >mech, and will likely never be used again: the precedent will be 
> >clear that no one will care to build mechanisms for one framework and 
> >then have then automatically available for the other, thus it will 
> >never be done for any other mechanisms.
> 
> Now I understand what you mean: You want to use SCRAM to get the kinks 
> out of GS2 and make sure that GS2 works in practice, right?

No, that's not it.  We're trying to avoid having to implement SCRAM for
SASL and SCRAM for GSS-API, but rather, implement one or the other, but
not both.

If you're a SASL implementor whose SASL implementation has no GS1 (the
original "GSSAPI" SASL mech in RFC2222) then you'd implement SCRAM as a
pure SASL mech, which would interop with any implementation of SCRAM as
a GSS-API mechanism used in SASL via GS2.

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 n1CD2dOk006832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 06:02:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1CD2dTB006831; Thu, 12 Feb 2009 06:02:39 -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 n1CD2S7u006823 for <[e-mail]>; Thu, 12 Feb 2009 06:02:39 -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 0D18B4AC5A; Thu, 12 Feb 2009 14:02:27 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1234443746-9030-1/6/144 (5 recipients); Thu, 12 Feb 2009 14:02:26 +0100
Message-Id: <lu8I0w0+TyOhQ3qrWyFgRA.md5@lochnagar>
Date: Thu, 12 Feb 2009 14:03:29 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, Simon Josefsson <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[e-mail]> <[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>

Nicolas Williams writes:
> If we drop SCRAM-as-GS2 then GS2 will be useful only for the krb5 
> mech, and will likely never be used again: the precedent will be 
> clear that no one will care to build mechanisms for one framework and 
> then have then automatically available for the other, thus it will 
> never be done for any other mechanisms.

Now I understand what you mean: You want to use SCRAM to get the kinks 
out of GS2 and make sure that GS2 works in practice, right?

I don't think SCRAM is a great driver for GS2, then. GS2 wants something 
that is needed on both sides of the fence, and will be scrutinised and 
used on both sides. SCRAM's needed very much more on the SASL side.

But I'll spend some time on SCRAM-GS2. Even if it doesn't help SCRAM it 
can help you, and now I'm not afraid of a quagmire thread any more.

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 n1CANta9097108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 03:23:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1CANtTI097107; Thu, 12 Feb 2009 03:23:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1CANfnh097096 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 12 Feb 2009 03:23:53 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LXYjK-0004ox-Qm; Thu, 12 Feb 2009 11:23:39 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090212:[e-mail]::XgqxRLnj4iJu6IHd:3NQL
X-Hashcash: 1:22:090212:[e-mail]::FcX+KBjKTR9kQLFc:60Pv
X-Hashcash: 1:22:090212:[e-mail]::nG8fO71iudpQlwhm:52vk
X-Hashcash: 1:22:090212:[e-mail]::R4vtub9aCvKSCDmA:7+1M
Date: Thu, 12 Feb 2009 11:23:37 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 11 Feb 2009 10:44:41 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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 Wed, Feb 11, 2009 at 01:55:49PM +0100, Simon Josefsson wrote:
>> Arnt Gulbrandsen <[e-mail]> writes:
>> 
>> > I do hope GS2 has a purpose in life other than to support SCRAM, though.
>> 
>> Definitely.  My main motivation to work on it has been to bridge
>> together SASL and GSS-API.  Another has been to improve Kerberos V5
>> authentication by reducing round-trips.  A third is to add channel
>> binding support, which makes it possible to re-use TLS for security
>> layer with Kerberos V5.
>
> I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
> only for the krb5 mech, and will likely never be used again: the
> precedent will be clear that no one will care to build mechanisms for
> one framework and then have then automatically available for the other,
> thus it will never be done for any other mechanisms.

I'm less convinced of that.  I want to see a password-based GSS-API
mechanism, which would be possible to use in SASL via GS2, so there will
be at least one.  I agree pure-SASL-SCRAM would set a precedent, but I
don't think it will prevent future work towards merging the GSS-API and
SASL frameworks.

/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 n1BGsNTd051265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 09:54:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BGsNxY051264; Wed, 11 Feb 2009 09:54:23 -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 n1BGs7eZ051247 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 11 Feb 2009 09:54:17 -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 n1BGrs3G009096 for <[e-mail]>; Wed, 11 Feb 2009 16:54:07 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 n1BGrs0V043483 for <[e-mail]>; Wed, 11 Feb 2009 09:53:54 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1BGiwOm017054; Wed, 11 Feb 2009 10:45:02 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1BGif6P017053; Wed, 11 Feb 2009 10:44:41 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 11 Feb 2009 10:44:41 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[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 Wed, Feb 11, 2009 at 01:55:49PM +0100, Simon Josefsson wrote:
> Arnt Gulbrandsen <[e-mail]> writes:
> 
> > I do hope GS2 has a purpose in life other than to support SCRAM, though.
> 
> Definitely.  My main motivation to work on it has been to bridge
> together SASL and GSS-API.  Another has been to improve Kerberos V5
> authentication by reducing round-trips.  A third is to add channel
> binding support, which makes it possible to re-use TLS for security
> layer with Kerberos V5.

I don't see the point.  If we drop SCRAM-as-GS2 then GS2 will be useful
only for the krb5 mech, and will likely never be used again: the
precedent will be clear that no one will care to build mechanisms for
one framework and then have then automatically available for the other,
thus it will never be done for any other mechanisms.



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 n1BDKq9N039775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 06:20:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BDKplZ039774; Wed, 11 Feb 2009 06:20:51 -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 n1BDKe5h039765 for <[e-mail]>; Wed, 11 Feb 2009 06:20:50 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Wed, 11 Feb 2009 13:20:38 +0000
X-SMTP-Protocol-Errors: NORDNS
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Wed, 11 Feb 2009 05:20:33 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 11, 2009, at 4:48 AM, Simon Josefsson wrote:

> Nicolas Williams <[e-mail]> writes:
>
>> On Tue, Feb 10, 2009 at 01:14:06PM -0800, Kurt Zeilenga wrote:
>>> On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:
>>>> In so far as security layers are optional, yes, but a) that has no
>>>> relationship to whether the implementation is a pure SASL one or a
>>>> GS2/GSS-API based one, and b) that should have no effect on
>>>> interoperability in the common case where SASL is run over TLS.
>>>
>>> Do you expect SASL-GS2 I-D to be revised to detail how to implement
>>> these security layer?

I should have said GS2-SCRAM I-D here.

That is, I was wondering what the GS2-SCRAM I-D not about GS2 I-D  
itself.


>> Given that SASL-GS2 security layers would be optional, but also  
>> that the
>> basis for an integrity protection layer being part of the SCRAM
>> internals for channel binding, IMO:
>>
>> - the spec should describe the integrity protection security layer
>> - the spec need not describe a privacy protection (encryption)  
>> security
>>   layer, which can then be provided by a separate I-D.
>
> I may be missing something, but the SASL GS2 document describes how  
> SASL
> security layers are implemented via GSS_Wrap/GSS_Unwrap.   
> Optionally, as
> you describe.




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 n1BD2nQV038771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 06:02:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BD2n3B038770; Wed, 11 Feb 2009 06:02:49 -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 n1BD2mIA038762 for <[e-mail]>; Wed, 11 Feb 2009 06:02:49 -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 9ED684AC5A; Wed, 11 Feb 2009 14:02:47 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1234357367-9030-1/6/139 (5 recipients); Wed, 11 Feb 2009 14:02:47 +0100
Message-Id: <+JxLpw2NMq6m4l1kU7aUJA.md5@lochnagar>
Date: Wed, 11 Feb 2009 14:03:48 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Simon Josefsson <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> <[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>

Simon Josefsson writes:
> Arnt Gulbrandsen <[e-mail]> writes:
>
>>  I do hope GS2 has a purpose in life other than to support SCRAM, though.
>
> Definitely. My main motivation to work on it has been to bridge 
> together SASL and GSS-API. Another has been to improve Kerberos V5 
> authentication by reducing round-trips. A third is to add channel 
> binding support, which makes it possible to re-use TLS for security 
> layer with Kerberos V5.

Glad to hear that.

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 n1BCtw8o038491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 05:55:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BCtwGe038490; Wed, 11 Feb 2009 05:55: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-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1BCtt21038481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Feb 2009 05:55:57 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LXEd8-0002QS-4q; Wed, 11 Feb 2009 13:55:54 +0100
From: Simon Josefsson <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090211:[e-mail]::3Wza1UdS290Cq6r5:8AM
X-Hashcash: 1:22:090211:[e-mail]::/CUaEZeFIouBs4VO:1TAy
X-Hashcash: 1:22:090211:[e-mail]::A6Ql4pAVLOafnYkQ:2qeX
X-Hashcash: 1:22:090211:[e-mail]::Z9aloDINA1EPx9ch:7sIQ
Date: Wed, 11 Feb 2009 13:55:49 +0100
In-Reply-To: <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar> (Arnt Gulbrandsen's message of "Wed, 11 Feb 2009 11:31:01 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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>

Arnt Gulbrandsen <[e-mail]> writes:

> I do hope GS2 has a purpose in life other than to support SCRAM, though.

Definitely.  My main motivation to work on it has been to bridge
together SASL and GSS-API.  Another has been to improve Kerberos V5
authentication by reducing round-trips.  A third is to add channel
binding support, which makes it possible to re-use TLS for security
layer with Kerberos V5.

/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 n1BCqJvC038346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 05:52:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BCqJoA038345; Wed, 11 Feb 2009 05:52:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1BCqHkt038335 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Feb 2009 05:52:18 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LXEZc-0002QL-Oy; Wed, 11 Feb 2009 13:52:17 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Hallvard B Furuseth <[e-mail]>, Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090211:[e-mail]::64VRF3Uhnww3PKVV:0blz
X-Hashcash: 1:22:090211:[e-mail]::bkiuiGYX5NDS5Ct4:0CPR
X-Hashcash: 1:22:090211:[e-mail]::2w1wzNqrszM2+4h3:7SII
X-Hashcash: 1:22:090211:[e-mail]::lB5vB6794NVj536E:RS+X
X-Hashcash: 1:22:090211:[e-mail]::pbNP+a3DatmIOVuY:0BqFL
Date: Wed, 11 Feb 2009 13:52:15 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 10 Feb 2009 22:29:59 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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:

> The background, briefly:
>
>  - there exists SASL, with which you are familiar
>
>  - there also exists the GSS-API, with which you are not
>
>  - the two are very similar
>
>  - yet also different enough that mechanisms for one are usually not
>    available for the other
>
>  - we are annoyed by this
>
>  - we want to fix this
>
>  - enter GS1 (the GSS part of RFC2222), the first attempt to bridge SASL
>    and the GSS-API
>
>     - the differences between the two frameworks, SASL and the GSS-API,
>       are such that the GSS-API is the more general framework, which
>       means it's easier to make GSS mechanisms available to SASL than
>       the reverse
>
>  - GS1 has problems that we'd like to fix
>
>  - enter MD5's breaks
>
>  - we also want a replacement for DIGEST/CRAM-MD5
>
> The proposal, briefly:
>
>  - create a replacement for GS1, which we'll call GS2
>
>  - create a replacement for DIGEST/CRAM-MD5, which we'll call SCRAM
>
>  - make SCRAM a GSS-API mechanism so it can be used in GSS-API apps and,
>    through GS2, SASL apps
>
>  - BUT, because the SASL crowd generally looks askance at the GSS-API
>    and has balked at a pure-GSS-API SCRAM to be used through GS2...
>
>    ...we've also decided to describe SCRAM as a pure SASL mechanism that
>    just happens to match, on the wire, what a GSS-API mechanism used in
>    SASL via GS2 would look like.

Very good summary, I think this clears up many things that may have been
poorly understood so far.

What seems to be missing is a document that describes SCRAM as a GSS-API
mechanism.  I talked with Alexey at FOSDEM and got the nroff source to
SCRAM, so I am working on preparing such a document.  When we have a
concrete document, the pure-SASL crowd can evaluate whether the
perceived complexities with SCRAM-via-GS2 are real or not.

/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 n1BCmXtY038160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 05:48:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BCmXGa038159; Wed, 11 Feb 2009 05:48:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1BCmK7W038134 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Feb 2009 05:48:32 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LXEVl-0002QF-2O; Wed, 11 Feb 2009 13:48:17 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090211:[e-mail]::WpYlJTT49KtEWxkH:o91
X-Hashcash: 1:22:090211:[e-mail]::8JI3qHyHHsijaSlW:2/JH
X-Hashcash: 1:22:090211:[e-mail]::U/yu8CHGa8pZ3qVY:J5GH
X-Hashcash: 1:22:090211:[e-mail]::FZ5RA1LB47DsyXRN:JapB
Date: Wed, 11 Feb 2009 13:48:15 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 10 Feb 2009 15:22:36 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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, Feb 10, 2009 at 01:14:06PM -0800, Kurt Zeilenga wrote:
>> On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:
>> >In so far as security layers are optional, yes, but a) that has no
>> >relationship to whether the implementation is a pure SASL one or a
>> >GS2/GSS-API based one, and b) that should have no effect on
>> >interoperability in the common case where SASL is run over TLS.
>> 
>> Do you expect SASL-GS2 I-D to be revised to detail how to implement  
>> these security layer?
>
> Given that SASL-GS2 security layers would be optional, but also that the
> basis for an integrity protection layer being part of the SCRAM
> internals for channel binding, IMO:
>
>  - the spec should describe the integrity protection security layer
>  - the spec need not describe a privacy protection (encryption) security
>    layer, which can then be provided by a separate I-D.

I may be missing something, but the SASL GS2 document describes how SASL
security layers are implemented via GSS_Wrap/GSS_Unwrap.  Optionally, as
you describe.

/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 n1BAUFIL029186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 03:30:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1BAUFBc029185; Wed, 11 Feb 2009 03:30:15 -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 n1BAU2T6029165 for <[e-mail]>; Wed, 11 Feb 2009 03:30:14 -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 6CA164AC50; Wed, 11 Feb 2009 11:30:01 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1234348200-9030-1/6/137 (4 recipients); Wed, 11 Feb 2009 11:30:00 +0100
Message-Id: <RQ9L+XtqbioLTHUL04SY7w.md5@lochnagar>
Date: Wed, 11 Feb 2009 11:31:01 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Nicolas Williams writes:
> No one is saying what the specific problems are, and we in the 
> SCRAM-as-GS2-mech crowd have bent over backwards trying to identify 
> those problems and then change GS2 so as to make those problems go 
> away, but our only reward is "I only want a refinement of 
> DIGEST/CRAM-MD5."

Would you expect otherwise?

Digest-MD5's interoperability problems aren't going away and MD5 is 
growing weaker by the month, so I think it's perfectly natural to want 
a C/D-MD5 replacement and want that strongly.

As far as I could tell by reading the documents, GS2 doesn't _help_ 
SCRAM towards being as widely implemented as C/D-MD5. The question is: 
a) Does it harm? b) Does it harm too much? And you want me (and others) 
to answer c) What specifically harms?.

My answers are: a) Yes, it harms. b) It harms enough that I wasn't sure 
whether the two drafts described the same mechanism (ignoring 
differences in constant strings) and I have a theory that other people 
are about as stupid as I am. One implication of that is that if I can't 
comprehend a document with reasonable effort, then that document is too 
demanding of its readers. If the document is too demanding of its 
readers, then it harms SCRAM too much. So yes.

Given the "yes" to b), spending time on question c) is really a fool's 
errand for me. I'm not interested in GS2 and answering c) properly 
seems like it would take a lot of time, and that after spending that 
time I'd sit there discussing how to harm SCRAM less while still 
harming it. I'd MUCH rather not spend the time, not harm SCRAM at all 
and not get into that discussion.

> What really bugs me is that outside Chris we've had very, very little 
> help in making SCRAM acceptable to the SCRAM-as-pure-SASL-mech crowd. 
> Thus I think Sam, Simon, myself and others have basically spent 
> enormous amounts of time only to have this poll on whether we're now 
> going to throw that out the window.

True.

I do hope GS2 has a purpose in life other than to support SCRAM, though.

FWIW, I did try to open my mouth a couple of years ago. Someone told me 
"I think it can be written well enough" and I had no way to answer 
that. So I shut up and stepped away. I apologise for not trying harder 
to find a third way.

>>  I don't know which things people find difficult and would like to 
>>  find out. Or rather I would not tell my opinion until I hear some 
>>  feedback.
>
> We will never be told.

If could could come up with an argument that GS2 would make SCRAM be 
easier to implement and more widely implemented, I think you would.

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 n1B4dNQk015032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 21:39:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1B4dNHE015030; Tue, 10 Feb 2009 21:39:23 -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-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1B4dBcl014887 for <[e-mail]>; Tue, 10 Feb 2009 21:39:21 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1B4dAj6002268 for <[e-mail]>; Wed, 11 Feb 2009 04:39:10 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 n1B4dAl3018643 for <[e-mail]>; Tue, 10 Feb 2009 21:39:10 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1B4UDju016610; Tue, 10 Feb 2009 22:30:18 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1B4TxN7016609; Tue, 10 Feb 2009 22:29:59 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 22:29:59 -0600
From: Nicolas Williams <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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, Feb 10, 2009 at 10:17:35PM +0100, Hallvard B Furuseth wrote:
> Nicolas Williams writes:
> > The normative reference is needed because though scram-gs2 is not
> > described as a GSS-API mechanism it needs to conform to GS2, and that
> > is only relevant to GS2 implementors, whereas SCRAM implementors who
> > don't have a GSS-API implementation need not implement GS2.
> 
> Speaking as someone who has not followed the GSS-API discussions,
> that sure confuses me.  I don't understand what this draft is doing,
> so presumably I still wouldn't if I encountered it as an RFC.

OK.

The background, briefly:

 - there exists SASL, with which you are familiar

 - there also exists the GSS-API, with which you are not

 - the two are very similar

 - yet also different enough that mechanisms for one are usually not
   available for the other

 - we are annoyed by this

 - we want to fix this

 - enter GS1 (the GSS part of RFC2222), the first attempt to bridge SASL
   and the GSS-API

    - the differences between the two frameworks, SASL and the GSS-API,
      are such that the GSS-API is the more general framework, which
      means it's easier to make GSS mechanisms available to SASL than
      the reverse

 - GS1 has problems that we'd like to fix

 - enter MD5's breaks

 - we also want a replacement for DIGEST/CRAM-MD5

The proposal, briefly:

 - create a replacement for GS1, which we'll call GS2

 - create a replacement for DIGEST/CRAM-MD5, which we'll call SCRAM

 - make SCRAM a GSS-API mechanism so it can be used in GSS-API apps and,
   through GS2, SASL apps

 - BUT, because the SASL crowd generally looks askance at the GSS-API
   and has balked at a pure-GSS-API SCRAM to be used through GS2...

   ...we've also decided to describe SCRAM as a pure SASL mechanism that
   just happens to match, on the wire, what a GSS-API mechanism used in
   SASL via GS2 would look like.

> Also I haven't caught the motivation for the combined SASL + GSS-API
> draft.  People have mentioned code reuse, I don't know if there is
> anything else.

And specification reuse.

> Is there a summary somewhere of why things are done this way?

There is above.  If the I-Ds don't capture this, they probably should.

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 n1ALVbBl000489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 14:31:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ALVbE9000488; Tue, 10 Feb 2009 14:31:37 -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 n1ALVRo7000481 for <[e-mail]>; Tue, 10 Feb 2009 14:31:37 -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 n1ALVR0b022623 for <[e-mail]>; Tue, 10 Feb 2009 21:31:27 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 n1ALVQSv062845 for <[e-mail]>; Tue, 10 Feb 2009 14:31:27 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1ALMaNO016160; Tue, 10 Feb 2009 15:22:36 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1ALMadl016159; Tue, 10 Feb 2009 15:22:36 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 15:22:36 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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, Feb 10, 2009 at 01:14:06PM -0800, Kurt Zeilenga wrote:
> On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:
> >In so far as security layers are optional, yes, but a) that has no
> >relationship to whether the implementation is a pure SASL one or a
> >GS2/GSS-API based one, and b) that should have no effect on
> >interoperability in the common case where SASL is run over TLS.
> 
> Do you expect SASL-GS2 I-D to be revised to detail how to implement  
> these security layer?

Given that SASL-GS2 security layers would be optional, but also that the
basis for an integrity protection layer being part of the SCRAM
internals for channel binding, IMO:

 - the spec should describe the integrity protection security layer
 - the spec need not describe a privacy protection (encryption) security
   layer, which can then be provided by a separate I-D.

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 n1ALTMDr000407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 14:29:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ALTMLG000406; Tue, 10 Feb 2009 14:29: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-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 n1ALTCir000392 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 10 Feb 2009 14:29:22 -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 n1ALTBjR007425 for <[e-mail]>; Tue, 10 Feb 2009 21:29:11 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 n1ALTB8v061046 for <[e-mail]>; Tue, 10 Feb 2009 14:29:11 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1ALKKPF016152; Tue, 10 Feb 2009 15:20:20 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1ALKKG6016151; Tue, 10 Feb 2009 15:20:20 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 15:20:20 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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, Feb 10, 2009 at 09:06:25PM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Certainly "neither" is not a good answer, because then there'd be no
> >authoritative specification :)
> >
> >However, SCRAM-as-GS2 must stand on its own if pure-SASL implementors
> >are to be happy, yet it needs to conform to GS2 if we are to have
> >interop with SASL/GS2 implementors.
> 
> I agree with both statements.
> 
> >>I would argue that if we further pursue the scram-gs2 approach, I  
> >>would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
> >>informational.   I would add that SCRAM-GS2 should include text that  
> >>clearly states it is not definitive.
> >
> >I'd be happy with that.
> >
> I would be less happy about that and I don't think a statement like this 
> is going to be helpful, even if it is true.

Indeed, my next paragraph foresaw such a reaction.

Which is why I think that a SCRAM-as-GS2-but-described-normatively-
only-as-pure-SASL approach is the best approach: it puts the burden on
the GS2 implementors to ensure that the SCRAM specification is indeed
interoperable with GS2 and does allow for a SCRAM GSS-API mechanism.

And all without burdening pure-SASL implementors with having to read and
understand GS2 nor the GSS-API.

That is a compromise which I think we in the GS2 camp must be willing to
make in order to get SCRAM-as-GS2.  Otherwise we'd be asking too much of
the pure SASL crowd.

> >But pure SASL implementors might not be, in
> >which case we'll need to make a) the SCRAM specification independent of
> >GS2 yet b) conformant to it.  I have long assumed we'd have to do just
> >that.


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 n1ALPWup000299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 14:25:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ALPWq6000298; Tue, 10 Feb 2009 14:25:32 -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 n1ALPUlH000292 for <[e-mail]>; Tue, 10 Feb 2009 14:25:31 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 10 Feb 2009 21:25:29 +0000
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 13:25:24 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 10, 2009, at 1:17 PM, Hallvard B Furuseth wrote:

> Will a GSS-API mech be defined retoractively so it fits the SASM mech?
> It seems quite backwards for a GS2-* mech, instead of defining a GSS- 
> API
> mechanism first and SCRAM-GS2 on top of it.

I think it would be unwise to push GS2-SCRAM forward without the  
definitive specification it mimics being complete.

-- 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 n1ALNpQY000248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 14:23:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ALNp7B000247; Tue, 10 Feb 2009 14:23:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1ALNnBD000241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Feb 2009 14:23:51 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LX056-0006FH-P9; Tue, 10 Feb 2009 22:23:48 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx5.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LX055-0007ae-Ru; Tue, 10 Feb 2009 22:23:48 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LX055-0002Vv-QI; Tue, 10 Feb 2009 22:23:47 +0100
Message-Id: <[e-mail]>
From: Hallvard B Furuseth <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 10 Feb 2009 22:23:47 +0100
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 23D4E5CB198CC0F3C690E43FE47812B5587BD578
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 1376 max/h 8 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:
> Some uninformed ramblings follow anyway.  Feel free to interpret this
> as just a list of things that need to be summarized/clarified in the
> GS2-SASL document.  But in the mailinglist too if the poll is also
  ^^^^^^^^
Sorry, GS2-SCRAM document.

> addressed to people like me who haven't followed GS2.

-- 
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 n1ALHosl099968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 14:17:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ALHoLi099967; Tue, 10 Feb 2009 14:17:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1ALHciY099958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Feb 2009 14:17:50 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LWzz6-0003E2-MD; Tue, 10 Feb 2009 22:17:36 +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 1LWzz6-0001vn-DI; Tue, 10 Feb 2009 22:17:36 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LWzz5-0002V7-Sr; Tue, 10 Feb 2009 22:17:35 +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, 10 Feb 2009 22:17:35 +0100
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: E27C01E7A63E58182F686593FB9AE977B13BEA74
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1375 max/h 8 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:
> The normative reference is needed because though scram-gs2 is not
> described as a GSS-API mechanism it needs to conform to GS2, and that
> is only relevant to GS2 implementors, whereas SCRAM implementors who
> don't have a GSS-API implementation need not implement GS2.

Speaking as someone who has not followed the GSS-API discussions,
that sure confuses me.  I don't understand what this draft is doing,
so presumably I still wouldn't if I encountered it as an RFC.

Also I haven't caught the motivation for the combined SASL + GSS-API
draft.  People have mentioned code reuse, I don't know if there is
anything else.

Is there a summary somewhere of why things are done this way?

Some uninformed ramblings follow anyway.  Feel free to interpret this
as just a list of things that need to be summarized/clarified in the
GS2-SASL document.  But in the mailinglist too if the poll is also
addressed to people like me who haven't followed GS2.


This document doesn't define a GSS-API mechanism, so what is it doing?
Will a GSS-API mech be defined retoractively so it fits the SASM mech?
It seems quite backwards for a GS2-* mech, instead of defining a GSS-API
mechanism first and SCRAM-GS2 on top of it.

Nor does it appear to define a valid SASL GS2 mechanism, since it barely
spells out any GS2/GSS-API semantics.  At least, I presume these do have
some semantics which will need to affect a SASL mechanism - but maybe
there is so little of it that it can mostly be reduced to grammar, like
this draft does?  Seems likely enough for producing SCRAM-GS2 messages,
but it'd need to handle incoming messages from a full GSS-API SCRAM too.
If it already does, the draft needs to reassure readers on that.

Also, what happens when GS2 gets updated/obsoleted?  Does SCRAM and
other mechanisms that are defined the same way get left behind?

So all in all it seems strange to put this in the SCRAM spec.  Looks
like a better place would be for the GS2 spec to have a section on how
one could design and implement a SASL GS2 mechanism without bothering
with GSS-API.  With a template mechanism grammar, maybe.  Then SCRAM
could defer to that, and maybe import it as an informative appendix.

Yes, I know that makes the document more complex, but it seems the
proper way to do a GS2-* SCRAM to me.

If we instead are to have separate SASL SCRAM and GSS-API SCRAMs, an
alternative I haven't seen mentioned would be to design SCRAM so that
the GSS-API variant could be coded as if it were an extension to SASL
SCRAM.  These mechs would have different names: "SCRAM" vs "GS2-xxxx".
I don't know if that fits the motivation for trying to join the
documents though.

Anyway, this would first mean to make plain SCRAM as GS2-friendly as
possible.  (Again, it might help for GS2 to have a "how to define a
GS2-friendly SASL mechanism" section.)  It'd need a more flexible
extension mechanism than m=, but that should be simple.  I'll be
getting back to 'm=' later anyway, now that I finally understand it.

-- 
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 n1ALED9m099887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 14:14:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1ALEDKG099886; Tue, 10 Feb 2009 14:14:13 -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 n1ALECHF099880 for <[e-mail]>; Tue, 10 Feb 2009 14:14:12 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 10 Feb 2009 21:14:10 +0000
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 13:14:06 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 10, 2009, at 12:12 PM, Nicolas Williams wrote:

>
> On Tue, Feb 10, 2009 at 11:48:58AM -0800, Kurt Zeilenga wrote:
>>
>> On Feb 10, 2009, at 9:58 AM, Nicolas Williams wrote:
>>
>>>
>>> On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
>>>>
>>>> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
>>>>
>>>>>
>>>>> On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
>>>>>> I would have assumed one difference between these two  
>>>>>> approaches is
>>>>>> that if SCRAM were implemented as a GSA-API, the GS2- variant  
>>>>>> would
>>>>>> be
>>>>>> capable of providing a SASL security layer.  If that were so,  
>>>>>> this
>>>>>> would lead to a significant interoperability problem as there  
>>>>>> would
>>>>>> be
>>>>>> two classes of support:
>>>>>> 	non-GSS-API implementations: no security layer (use TLS)
>>>>>> 	GSS-API implementations: GS2 security layer
>>>>>
>>>>> Nope.
>>>>
>>>> Then I might consider GS2-SCRAM as incomplete.  Given the goal that
>>>> GSS-API SCRAM be generally usable outside of SASL, it seems
>>>> appropriate for GSS-API SCRAM to support GSS-API wrapping.
>>>
>>> You misunderstood.  SCRAM would have GSS-API per-message tokens, but
>>> they'd be not needed in the common case (when TLS is used, and,
>>> therefore, channel binding is sufficient), thus optional.
>>
>> Will GS2-SCRAM provide a SASL security layer or not?
>
> Yes, but it's optional.  It's expected that the vast majority of the
> time channel binding to TLS will suffice.
>
>> If yes, then I think we'll have two distinct class of  
>> implementations.
>
> In so far as security layers are optional, yes, but a) that has no
> relationship to whether the implementation is a pure SASL one or a
> GS2/GSS-API based one, and b) that should have no effect on
> interoperability in the common case where SASL is run over TLS.

Do you expect SASL-GS2 I-D to be revised to detail how to implement  
these security layer?

-- 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 n1AL6rZJ099285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 14:06:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AL6rBT099284; Tue, 10 Feb 2009 14:06:53 -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 n1AL6gTX099256 for <[e-mail]>; Tue, 10 Feb 2009 14:06:53 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.222.93] (92.40.222.93.sub.mbb.three.co.uk [92.40.222.93])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 10 Feb 2009 21:06:41 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Feb 2009 21:06:25 +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: Nicolas Williams <[e-mail]>
CC: Kurt Zeilenga <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[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>

Nicolas Williams wrote:

>On Tue, Feb 10, 2009 at 12:17:32PM -0800, Kurt Zeilenga wrote:
>  
>
>>Question regarding the GS2-SCRAM specification.
>>
>>I see no language in draft-newman-auth-scram-gs2-00.txt which says  
>>whether it or the specifications detailing the SASL-GS2, GSS-API, GSS- 
>>API-SCRAM are definitive.
>>
>>Which will be?
>>
>>I don't think 'neither' or 'both' is an appealing (to me) answer here.
>>    
>>
>Certainly "neither" is not a good answer, because then there'd be no
>authoritative specification :)
>
>However, SCRAM-as-GS2 must stand on its own if pure-SASL implementors
>are to be happy, yet it needs to conform to GS2 if we are to have
>interop with SASL/GS2 implementors.
>  
>
I agree with both statements.

>>I would argue that if we further pursue the scram-gs2 approach, I  
>>would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
>>informational.   I would add that SCRAM-GS2 should include text that  
>>clearly states it is not definitive.
>>    
>>
>I'd be happy with that.
>
I would be less happy about that and I don't think a statement like this 
is going to be helpful, even if it is true.

>But pure SASL implementors might not be, in
>which case we'll need to make a) the SCRAM specification independent of
>GS2 yet b) conformant to it.  I have long assumed we'd have to do just
>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 n1AKiYSF098408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 13:44:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AKiYuT098407; Tue, 10 Feb 2009 13:44:34 -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 n1AKiNOD098396 for <[e-mail]>; Tue, 10 Feb 2009 13:44:34 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n1AKiNph009746 for <[e-mail]>; Tue, 10 Feb 2009 20:44:23 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 n1AKiNP0027935 for <[e-mail]>; Tue, 10 Feb 2009 13:44:23 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AKZWQ4016106; Tue, 10 Feb 2009 14:35:32 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AKZWVu016105; Tue, 10 Feb 2009 14:35:32 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 14:35:32 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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, Feb 10, 2009 at 12:17:32PM -0800, Kurt Zeilenga wrote:
> Question regarding the GS2-SCRAM specification.
> 
> I see no language in draft-newman-auth-scram-gs2-00.txt which says  
> whether it or the specifications detailing the SASL-GS2, GSS-API, GSS- 
> API-SCRAM are definitive.
> 
> Which will be?
> 
> I don't think 'neither' or 'both' is an appealing (to me) answer here.

Certainly "neither" is not a good answer, because then there'd be no
authoritative specification :)

However, SCRAM-as-GS2 must stand on its own if pure-SASL implementors
are to be happy, yet it needs to conform to GS2 if we are to have
interop with SASL/GS2 implementors.

> I would argue that if we further pursue the scram-gs2 approach, I  
> would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
> informational.   I would add that SCRAM-GS2 should include text that  
> clearly states it is not definitive.

I'd be happy with that.  But pure SASL implementors might not be, in
which case we'll need to make a) the SCRAM specification independent of
GS2 yet b) conformant to it.  I have long assumed we'd have to do just
that.

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 n1AKLbZt097344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 13:21:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AKLbjf097343; Tue, 10 Feb 2009 13:21:37 -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 n1AKLbwX097337 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 10 Feb 2009 13:21:37 -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 n1AKLaxO017862 for <[e-mail]>; Tue, 10 Feb 2009 20:21:36 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 n1AKLaLk010983 for <[e-mail]>; Tue, 10 Feb 2009 13:21:36 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AKCjO1016079; Tue, 10 Feb 2009 14:12:45 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AKCjT3016078; Tue, 10 Feb 2009 14:12:45 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 14:12:45 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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, Feb 10, 2009 at 11:48:58AM -0800, Kurt Zeilenga wrote:
> 
> On Feb 10, 2009, at 9:58 AM, Nicolas Williams wrote:
> 
> >
> >On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
> >>
> >>On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
> >>
> >>>
> >>>On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
> >>>>I would have assumed one difference between these two approaches is
> >>>>that if SCRAM were implemented as a GSA-API, the GS2- variant would
> >>>>be
> >>>>capable of providing a SASL security layer.  If that were so, this
> >>>>would lead to a significant interoperability problem as there would
> >>>>be
> >>>>two classes of support:
> >>>>	non-GSS-API implementations: no security layer (use TLS)
> >>>>	GSS-API implementations: GS2 security layer
> >>>
> >>>Nope.
> >>
> >>Then I might consider GS2-SCRAM as incomplete.  Given the goal that
> >>GSS-API SCRAM be generally usable outside of SASL, it seems
> >>appropriate for GSS-API SCRAM to support GSS-API wrapping.
> >
> >You misunderstood.  SCRAM would have GSS-API per-message tokens, but
> >they'd be not needed in the common case (when TLS is used, and,
> >therefore, channel binding is sufficient), thus optional.
> 
> Will GS2-SCRAM provide a SASL security layer or not?

Yes, but it's optional.  It's expected that the vast majority of the
time channel binding to TLS will suffice.

> If yes, then I think we'll have two distinct class of implementations.

In so far as security layers are optional, yes, but a) that has no
relationship to whether the implementation is a pure SASL one or a
GS2/GSS-API based one, and b) that should have no effect on
interoperability in the common case where SASL is run over TLS.

> If no, I think GS2-SCRAM is incomplete.

It's not incomplete, not in this sense.

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 n1AKHcxR097251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 13:17:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AKHcYj097250; Tue, 10 Feb 2009 13:17:38 -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 n1AKHaHU097244 for <[e-mail]>; Tue, 10 Feb 2009 13:17:37 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 10 Feb 2009 20:17:36 +0000
Cc: SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 12:17:32 -0800
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

Question regarding the GS2-SCRAM specification.

I see no language in draft-newman-auth-scram-gs2-00.txt which says  
whether it or the specifications detailing the SASL-GS2, GSS-API, GSS- 
API-SCRAM are definitive.

Which will be?

I don't think 'neither' or 'both' is an appealing (to me) answer here.

I would argue that if we further pursue the scram-gs2 approach, I  
would favor the approach suggested by Simon.  That is, SCRAM-GS2 be  
informational.   I would add that SCRAM-GS2 should include text that  
clearly states it is not definitive.

-- Kurt


On Feb 5, 2009, at 1:14 PM, Alexey Melnikov wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice  
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short  
> explanation of why) to the mailing list, or say if you need more  
> information.
>
> I would like to get all answers before February 19th, please.
>
> Regards,
> Alexey
>



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 n1AJn5Ps095969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 12:49:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AJn5B2095968; Tue, 10 Feb 2009 12:49:05 -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 n1AJn3eU095962 for <[e-mail]>; Tue, 10 Feb 2009 12:49:04 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 10 Feb 2009 19:49:02 +0000
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 11:48:58 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
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>

On Feb 10, 2009, at 9:58 AM, Nicolas Williams wrote:

>
> On Tue, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
>>
>> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
>>
>>>
>>> On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
>>>> I would have assumed one difference between these two approaches is
>>>> that if SCRAM were implemented as a GSA-API, the GS2- variant would
>>>> be
>>>> capable of providing a SASL security layer.  If that were so, this
>>>> would lead to a significant interoperability problem as there would
>>>> be
>>>> two classes of support:
>>>> 	non-GSS-API implementations: no security layer (use TLS)
>>>> 	GSS-API implementations: GS2 security layer
>>>
>>> Nope.
>>
>> Then I might consider GS2-SCRAM as incomplete.  Given the goal that
>> GSS-API SCRAM be generally usable outside of SASL, it seems
>> appropriate for GSS-API SCRAM to support GSS-API wrapping.
>
> You misunderstood.  SCRAM would have GSS-API per-message tokens, but
> they'd be not needed in the common case (when TLS is used, and,
> therefore, channel binding is sufficient), thus optional.

Will GS2-SCRAM provide a SASL security layer or not?

If yes, then I think we'll have two distinct class of implementations.
If no, I think GS2-SCRAM is incomplete.

-- 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 n1AIEEer092041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 11:14:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AIEEHs092040; Tue, 10 Feb 2009 11:14: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 n1AIE3Ng092022 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 10 Feb 2009 11:14:14 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1AIE3ZT010367 for <[e-mail]>; Tue, 10 Feb 2009 18:14:03 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 n1AIE2oe014821 for <[e-mail]>; Tue, 10 Feb 2009 11:14:02 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AI5ChC015571; Tue, 10 Feb 2009 12:05:12 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AI5Cbs015570; Tue, 10 Feb 2009 12:05:12 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 12:05:12 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
> >>Regardless of this, I simply don't thing scram-gs2 is "simple"  
> >>enough.
> >
> >Details.  Please provide details.
> 
> Of course, "simple" enough is quite subjective characteristic.   When  
> I first said this it was a gut reaction.  Here are some things which  
> lead me to my characterization of SCRAM-GS2 not being "simple" enough.

The WG has only been dealing with this for, what, two, three years, and
the chair is still going by gut reactions?

> Draft-newman-auth-scram-gs2-00.txt contains a normative reference to  
> draft-ietf-sasl-gs2-10.txt.  This implies an implementor must read and  
> understand draft-ietf-sasl-gs2-10.txt, as well as elements of its  
> normative references, in order to implement the protocol.  (I doubt  
> this normative reference can be downgraded.)

The normative reference is needed because though scram-gs2 is not
described as a GSS-API mechanism it needs to conform to GS2, and that is
only relevant to GS2 implementors, whereas SCRAM implementors who don't
have a GSS-API implementation need not implement GS2.

Thus this is not a real concern.

> The GS2 ABNF is twice as long.

Thank you, this is a relevant detail.  I'm not sure what we can do about
this, but I can take a look and see if there are simplifications we can
do.

> Not written in the GS2 specification, but needed to ensure broad
> adoption, is interoperability between the two classes of
> implementations.  Interoperability between classes of implementations
> is quite difficult to achieve in general, and the best way (I think)
> to avoid such interoperability problems is not to have classes of
> implementation.

SCRAM-as-GS2 is designed to be interoperable whether the implementor
chooses to implement it as a native SASL mechanism or as a GSS-API
mechanism used through GS2.

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 n1AI7hVX091536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 11:07:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AI7h7F091535; Tue, 10 Feb 2009 11:07: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 n1AI7ggF091529 for <[e-mail]>; Tue, 10 Feb 2009 11:07:43 -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 n1AI7gcA012685 for <[e-mail]>; Tue, 10 Feb 2009 18:07:42 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 n1AI7goQ009482 for <[e-mail]>; Tue, 10 Feb 2009 11:07:42 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AHwqqi015564; Tue, 10 Feb 2009 11:58:52 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AHwpjD015563; Tue, 10 Feb 2009 11:58:51 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 11:58:51 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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, Feb 10, 2009 at 09:55:31AM -0800, Kurt Zeilenga wrote:
> 
> On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:
> 
> >
> >On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
> >>I would have assumed one difference between these two approaches is
> >>that if SCRAM were implemented as a GSA-API, the GS2- variant would  
> >>be
> >>capable of providing a SASL security layer.  If that were so, this
> >>would lead to a significant interoperability problem as there would  
> >>be
> >>two classes of support:
> >>	non-GSS-API implementations: no security layer (use TLS)
> >>	GSS-API implementations: GS2 security layer
> >
> >Nope.
> 
> Then I might consider GS2-SCRAM as incomplete.  Given the goal that  
> GSS-API SCRAM be generally usable outside of SASL, it seems  
> appropriate for GSS-API SCRAM to support GSS-API wrapping.

You misunderstood.  SCRAM would have GSS-API per-message tokens, but
they'd be not needed in the common case (when TLS is used, and,
therefore, channel binding is sufficient), thus optional.

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 n1AHtnOl090990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 10:55:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AHtne4090989; Tue, 10 Feb 2009 10:55:49 -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 n1AHtc4M090975 for <[e-mail]>; Tue, 10 Feb 2009 10:55:49 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SZG=[e-mail]>; Tue, 10 Feb 2009 17:55:35 +0000
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Tue, 10 Feb 2009 09:55:31 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

On Feb 10, 2009, at 7:59 AM, Nicolas Williams wrote:

>
> On Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
>> I would have assumed one difference between these two approaches is
>> that if SCRAM were implemented as a GSA-API, the GS2- variant would  
>> be
>> capable of providing a SASL security layer.  If that were so, this
>> would lead to a significant interoperability problem as there would  
>> be
>> two classes of support:
>> 	non-GSS-API implementations: no security layer (use TLS)
>> 	GSS-API implementations: GS2 security layer
>
> Nope.

Then I might consider GS2-SCRAM as incomplete.  Given the goal that  
GSS-API SCRAM be generally usable outside of SASL, it seems  
appropriate for GSS-API SCRAM to support GSS-API wrapping.

But for native SCRAM, I think it reasonable not to offer a mechanism  
given the implicit goal of keeping it simple (and hence relying solely  
relying TLS).

I see the goals of GS2-SCRAM and the goals of native SCRAM as somewhat  
divergent.

I'm not opposed to having both.  I rather have a simple native SASL/ 
SCRAM and a robust GSS-API SCRAM, then something which is neither.

> The idea was that because all these SASL apps rely on TLS today for
> session security what you'd do is SCRAM-as-GS2 with channel binding to
> TLS (wait for it: "channel binding is too complicated!" even though  
> it's
> just one more input into a hash/hmac that's already there and has to
> be).  Thus: no need for SASL/SCRAM security layers.
>
>> Regardless of this, I simply don't thing scram-gs2 is "simple"  
>> enough.
>
> Details.  Please provide details.

Of course, "simple" enough is quite subjective characteristic.   When  
I first said this it was a gut reaction.  Here are some things which  
lead me to my characterization of SCRAM-GS2 not being "simple" enough.

Draft-newman-auth-scram-gs2-00.txt contains a normative reference to  
draft-ietf-sasl-gs2-10.txt.  This implies an implementor must read and  
understand draft-ietf-sasl-gs2-10.txt, as well as elements of its  
normative references, in order to implement the protocol.  (I doubt  
this normative reference can be downgraded.)

The GS2 ABNF is twice as long.

Not written in the GS2 specification, but needed to ensure broad  
adoption, is interoperability between the two classes of  
implementations.  Interoperability between classes of implementations  
is quite difficult to achieve in general, and the best way (I think)  
to avoid such interoperability problems is not to have classes of  
implementation.

-- 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 n1AGHD0m085327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 09:17:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AGHD3v085326; Tue, 10 Feb 2009 09:17:13 -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 n1AGHCJA085320 for <[e-mail]>; Tue, 10 Feb 2009 09:17:13 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.6] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 10 Feb 2009 16:17:11 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 10 Feb 2009 16:16:51 +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: Nicolas Williams <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, Simon Josefsson <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[e-mail]> <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar> <[e-mail]> <[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>

Nicolas Williams wrote:

>On Sun, Feb 08, 2009 at 09:34:42AM +0100, Alexey Melnikov wrote:
>  
>
>>Arnt Gulbrandsen wrote:
>>    
>>
>>>As an alternative, might I suggest adding entirely separate, but 
>>>intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
>>>far as protocol goes, but intentionally similar enough that libraries 
>>>which implement both can refactor the code (parsing etc. excepted).
>>>      
>>>
>>That would be fine with me. While this is not ideal, I think it would be 
>>much easier to agree on this in the WG.
>>    
>>
>This would make GS2 pointless.
>  
>
I wouldn't say it is pointless. The experiment of trying to make SCRAM 
be a GS2 thing is a very useful thing, no matter what the outcome with 
SCRAM would be.



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 n1AG84Y1084548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 09:08:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AG84GE084547; Tue, 10 Feb 2009 09:08:04 -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 n1AG83R1084541 for <[e-mail]>; Tue, 10 Feb 2009 09:08:03 -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 n1AG83rE013067 for <[e-mail]>; Tue, 10 Feb 2009 16:08:03 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 n1AG83IU024010 for <[e-mail]>; Tue, 10 Feb 2009 09:08:03 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AFxDqM015456; Tue, 10 Feb 2009 09:59:13 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AFxDqQ015455; Tue, 10 Feb 2009 09:59:13 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 09:59:13 -0600
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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 Mon, Feb 09, 2009 at 01:09:43PM -0800, Kurt Zeilenga wrote:
> I would have assumed one difference between these two approaches is  
> that if SCRAM were implemented as a GSA-API, the GS2- variant would be  
> capable of providing a SASL security layer.  If that were so, this  
> would lead to a significant interoperability problem as there would be  
> two classes of support:
> 	non-GSS-API implementations: no security layer (use TLS)
> 	GSS-API implementations: GS2 security layer

Nope.

The idea was that because all these SASL apps rely on TLS today for
session security what you'd do is SCRAM-as-GS2 with channel binding to
TLS (wait for it: "channel binding is too complicated!" even though it's
just one more input into a hash/hmac that's already there and has to
be).  Thus: no need for SASL/SCRAM security layers.

> Regardless of this, I simply don't thing scram-gs2 is "simple" enough.

Details.  Please provide details.

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 n1AG4VQ1084306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 09:04:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AG4VDD084305; Tue, 10 Feb 2009 09:04:31 -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 n1AG4VZg084299 for <[e-mail]>; Tue, 10 Feb 2009 09:04:31 -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 n1AG4URu010750 for <[e-mail]>; Tue, 10 Feb 2009 16:04:30 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 n1AG4UHc021172 for <[e-mail]>; Tue, 10 Feb 2009 09:04:30 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AFtefU015450; Tue, 10 Feb 2009 09:55:40 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AFte8p015449; Tue, 10 Feb 2009 09:55:40 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 09:55:40 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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 Sun, Feb 08, 2009 at 09:26:20AM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >BUT, I don't understand this poll.  Why are we having it as opposed a
> >poll as to how to describe SCRAM?  Is it because SCRAM-as-GS2, even
> >described as a pure SASL mech, is too complicated?
> >
> I would say SCRAM-as-GS2 is slightly more complicated. I want to find 
> out what people think about the extra complexity.

No one is saying what the specific problems are, and we in the
SCRAM-as-GS2-mech crowd have bent over backwards trying to identify
those problems and then change GS2 so as to make those problems go away,
but our only reward is "I only want a refinement of DIGEST/CRAM-MD5."

What really bugs me is that outside Chris we've had very, very little
help in making SCRAM acceptable to the SCRAM-as-pure-SASL-mech crowd.
Thus I think Sam, Simon, myself and others have basically spent
enormous amounts of time only to have this poll on whether we're now
going to throw that out the window.

> Of course any input from people such as "if you change X to Y, or drop 
> Z, then the document would become reasonable", would be highly 
> constructive and would be appreciated.

Right, but that's not what's happening.

> >If so, what are the complicating issues that make it a deal breaker for 
> >others?
> 
> I don't know which things people find difficult and would like to find out.
> Or rather I would not tell my opinion until I hear some feedback.

We will never be told.

> >I have the feeling that instead of listing those issues and addressing
> >them we're just giving up.
> >
> I have so many free hours in any given day and I am afraid the two 
> proposals is the best I can do at the moment.
> Unless people will actively try to help me (by either making the choice 
> or by contributing some suggestions/text), I will give up very soon now.

We're not likely to come to an agreement.

I think instead we should all pursue whatever solution we think is
appropriate for our needs as individual I-Ds and see what happens.

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 n1AFuHZ0083660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 08:56:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AFuHaZ083659; Tue, 10 Feb 2009 08:56:17 -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 n1AFu5bT083629 for <[e-mail]>; Tue, 10 Feb 2009 08:56:15 -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 n1AFu4F5028836 for <[e-mail]>; Tue, 10 Feb 2009 15:56:04 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 n1AFu4uA013456 for <[e-mail]>; Tue, 10 Feb 2009 08:56:04 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AFl6bb015432; Tue, 10 Feb 2009 09:47:06 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AFkncs015431; Tue, 10 Feb 2009 09:46:49 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 09:46:49 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, Simon Josefsson <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[e-mail]> <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar> <[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 Sun, Feb 08, 2009 at 09:34:42AM +0100, Alexey Melnikov wrote:
> Arnt Gulbrandsen wrote:
> 
> >As an alternative, might I suggest adding entirely separate, but 
> >intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
> >far as protocol goes, but intentionally similar enough that libraries 
> >which implement both can refactor the code (parsing etc. excepted).
> 
> That would be fine with me. While this is not ideal, I think it would be 
> much easier to agree on this in the WG.

This would make GS2 pointless.



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 n1AFsXno083520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Feb 2009 08:54:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1AFsXHo083519; Tue, 10 Feb 2009 08:54:33 -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 n1AFsUVj083511 for <[e-mail]>; Tue, 10 Feb 2009 08:54:31 -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 n1AFsURS004888 for <[e-mail]>; Tue, 10 Feb 2009 15:54:30 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 n1AFsUGI012542 for <[e-mail]>; Tue, 10 Feb 2009 08:54:30 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n1AFjckl015425; Tue, 10 Feb 2009 09:45:40 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n1AFjGAR015424; Tue, 10 Feb 2009 09:45:16 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Feb 2009 09:45:16 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
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, Feb 06, 2009 at 05:49:05PM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >BUT, I don't understand this poll. Why are we having it as opposed a 
> >poll as to how to describe SCRAM? Is it because SCRAM-as-GS2, even 
> >described as a pure SASL mech, is too complicated?
> 
> I think so.
> 
> >If so, what are the complicating issues that make it a deal breaker 
> >for others?
> 
> I don't care _what_ they are. Let me explain.
> 
> What I want is a replacement for digest-md5 and/or cram-md5, neither 
> more nor less. GS2 is entirely irrelevant to me, EXCEPT:

I have no interest in a refinement to either that cannot be used as a
GSS-API mechanism too.

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 n19LA0Vj031932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2009 14:10:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n19LA0vv031931; Mon, 9 Feb 2009 14:10:00 -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 n19L9mjA031921 for <[e-mail]>; Mon, 9 Feb 2009 14:09:59 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.128] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Mon, 9 Feb 2009 21:09:46 +0000
Cc: SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Mon, 9 Feb 2009 13:09:43 -0800
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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>

I would have assumed one difference between these two approaches is  
that if SCRAM were implemented as a GSA-API, the GS2- variant would be  
capable of providing a SASL security layer.  If that were so, this  
would lead to a significant interoperability problem as there would be  
two classes of support:
	non-GSS-API implementations: no security layer (use TLS)
	GSS-API implementations: GS2 security layer

Regardless of this, I simply don't thing scram-gs2 is "simple" enough.

I favor pursing publication of draft-newman-auth-scram-08.txt over  
draft-newman-auth-scram-gs2-00.txt for the SASL "SCRAM" mechanism.  I  
would not object to separate design/implementation of GSA-API SCRAM  
mechanism as I do think GSS-API needs something like SCRAM.

-- Kurt (chair hat off)



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 n191HkLH075454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 18:17:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n191HkHR075453; Sun, 8 Feb 2009 18:17:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (orthanc.ca [208.86.224.138]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n191HYYx075444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 8 Feb 2009 18:17:45 -0700 (MST) (envelope-from [e-mail])
Received: from mm.wbb.net.cable.rogers.com (mm.wbb.net.cable.rogers.com [74.210.92.229]) (authenticated bits=0) by orthanc.ca (8.14.3/8.14.3) with ESMTP id n191HVQA043253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 8 Feb 2009 17:17:33 -0800 (PST) (envelope-from [e-mail])
Date: Sun, 8 Feb 2009 17:17:25 -0800 (PST)
From: Lyndon Nerenberg <[e-mail]>
To: [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[e-mail]>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Organization: The Frobozz Magic Homing Pigeon Company
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on orthanc.ca
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>

>> 2. If the mechanism and document are significantly complicated by the
>> requirements of GS2, then that's significantly worse.
>
> This sums up my position nicely. SCRAM is coming to the party very late 
> indeed, and because of that there's a pretty good chance it won't 
> deploy. Every bit of additional complexity in the specification 
> increases this chance.

> As such, I'm opposed to the GS2 approach unless it can be made to be as 
> simple or simpler than the direct approach. And from what I can tell 
> from the two specificaation that's not possible.

I'm in complete agreement with Ned on this.

It seems to me that the SASL WG is hell bent upon adding as much 
complexity as they can to everything they touch. Good security demands the 
absolute greatest amount of simplicity as can be attained while fulfilling 
the desired level of protection. This endless stacking of layer upon layer 
of protocol API serves only to add complexity to something that needs to 
be as simple and understandable as possible. If a human cannot parse and 
understand the protocol specification, there isn't a hope in hell they 
will be able to write a secure implementation.

I don't think GS2 even belongs inside the SASL framework. They both try to 
solve the same problem, therefore it's pointless (and redundent) for GS2 
to exist inside SASL to begin with. The two should exist side-by-side, 
letting the application protocol developers make the tradeoff between code 
complexity and desired security.

As for SCRAM vs. GS2-SCRAM, since the two cannot speak to each other on 
the wire they are by definition distinct and seperate protocols, and 
therefore demand distinct and seperate specficications. That much of the 
text might overlap doesn't change this fact. I realize it takes more work 
to write two seperate documents, but the onus upon this WG is to write 
specifications that above all else address the needs of the people who 
have to implement this stuff. Mixing two protocols in a single document is 
just slapping these people in the face.



--lyndon

   I think 3B2 code deserves its own place in hell.  Poring over the
   ESS#5 code, someone found that there were lots of strcmp(p, "f(")
   == 0 checks (I may have gotten the exact string wrong but it's
   close).  It took us a while to figure out why.  Apparently, location
   0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when
   programs blew up they were pointing to "f(", and the worlds most
   amazing kludge for detecting nil pointers was born.
   			-- Dave Presotto



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 n18AEWGj044911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 03:14:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n18AEW4u044910; Sun, 8 Feb 2009 03:14:32 -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 n18AEVCa044904 for <[e-mail]>; Sun, 8 Feb 2009 03:14:31 -0700 (MST) (envelope-from [e-mail])
Received: from [10.1.7.3] ((unknown) [164.15.34.77])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 8 Feb 2009 10:14:29 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 08 Feb 2009 09:34:42 +0100
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: Arnt Gulbrandsen <[e-mail]>
CC: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[e-mail]> <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar>
In-Reply-To: <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar>
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>

Arnt Gulbrandsen wrote:

> As an alternative, might I suggest adding entirely separate, but 
> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
> far as protocol goes, but intentionally similar enough that libraries 
> which implement both can refactor the code (parsing etc. excepted).

That would be fine with me. While this is not ideal, I think it would be 
much easier to agree on this in the WG.




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 n18AEOn3044900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 03:14:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n18AEOTS044899; Sun, 8 Feb 2009 03:14:24 -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 n18AEMBF044893 for <[e-mail]>; Sun, 8 Feb 2009 03:14:23 -0700 (MST) (envelope-from [e-mail])
Received: from [10.1.7.3] ((unknown) [164.15.34.77])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 8 Feb 2009 10:14:21 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 08 Feb 2009 09:27:21 +0100
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: Arnt Gulbrandsen <[e-mail]>
CC: Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
In-Reply-To: <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

Arnt Gulbrandsen wrote:

> 1. Making one document define SCRAM both in GS2 and pure SASL formats
> bloats the text. I want the document to be simple, so that _everyone_
> who today has a crammd5.c can write a scram.c _as_easily_as_ it was to
> write that crammd5.c. Bloating the document with an alternate
> definition is no help. People _will_ read the other half and _will_
> spend time trying to understand it, if only to decide what part they
> should understand and implement.

I think this can be easily avoided, if the document is structured correctly.




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 n18AEDaw044887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Feb 2009 03:14:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n18AED8E044886; Sun, 8 Feb 2009 03:14:13 -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 n18AE12p044878 for <[e-mail]>; Sun, 8 Feb 2009 03:14:12 -0700 (MST) (envelope-from [e-mail])
Received: from [10.1.7.3] ((unknown) [164.15.34.77])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 8 Feb 2009 10:13:59 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Sun, 08 Feb 2009 09:26:20 +0100
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: Nicolas Williams <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Nicolas Williams wrote:

>On Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>Are the two versions supposed to be the same protocol, but described
>>>differently?  Or are they different protocols?
>>>      
>>>
>>The two versions are slightly different on the wire - GS2 version 
>>requires different layout, different MIC to protect authorization 
>>identity, etc.
>>    
>>
>If it the same messages can't be reused to fashion a GSS mechanism then
>I'm not interested, so count me as in favor of SCRAM-as-GS2.
>
>BUT, I don't understand this poll.  Why are we having it as opposed a
>poll as to how to describe SCRAM?  Is it because SCRAM-as-GS2, even
>described as a pure SASL mech, is too complicated?
>
I would say SCRAM-as-GS2 is slightly more complicated. I want to find 
out what people think about the extra complexity.

Of course any input from people such as "if you change X to Y, or drop 
Z, then the document would become reasonable", would be highly 
constructive and would be appreciated.

>If so, what are the complicating issues that make it a deal breaker for others?
>  
>
I don't know which things people find difficult and would like to find out.
Or rather I would not tell my opinion until I hear some feedback.

>I have the feeling that instead of listing those issues and addressing
>them we're just giving up.
>
I have so many free hours in any given day and I am afraid the two 
proposals is the best I can do at the moment.
Unless people will actively try to help me (by either making the choice 
or by contributing some suggestions/text), I will give up very soon now.




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 n16LG26h067537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 14:16:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16LG2dF067536; Fri, 6 Feb 2009 14:16:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16LG0er067527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 6 Feb 2009 14:16:01 -0700 (MST) (envelope-from [e-mail])
Received: from 62-50-194-107.client.stsn.net ([62.50.194.107] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LVY3K-0004yl-H1; Fri, 06 Feb 2009 22:15:58 +0100
From: Simon Josefsson <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[e-mail]> <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar> <[e-mail]> <aeJsQreLcQ7zjGbJ3+gvhQ.md5@lochnagar>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090206:[e-mail]::8U52xWA/NtrccSqY:FEcN
X-Hashcash: 1:22:090206:[e-mail]::Xn/XpXKLOD8ORaxL:HBfg
X-Hashcash: 1:22:090206:[e-mail]::uiAsmyLxzAdN6twC:K+I3
X-Hashcash: 1:22:090206:[e-mail]::94hjkwsDSXX4SXGP:PwrD
Date: Fri, 06 Feb 2009 22:15:51 +0100
In-Reply-To: <aeJsQreLcQ7zjGbJ3+gvhQ.md5@lochnagar> (Arnt Gulbrandsen's message of "Fri, 6 Feb 2009 22:04:13 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED,AWL,TVD_RCVD_IP autolearn=no version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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>

Arnt Gulbrandsen <[e-mail]> writes:

> Simon Josefsson writes:
>> Arnt Gulbrandsen <[e-mail]> writes:
>>> As an alternative, might I suggest adding entirely separate, but
>>> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship
>>> as far as protocol goes, but intentionally similar enough that
>>> libraries which implement both can refactor the code (parsing
>>> etc. excepted).
>>
>> Which SASL mechanism name should be used for these two different protocols?
>
> "SCRAM" for SCRAM. I presume the GSS-API one would be reachable in
> SASL both as "GS2-1FAD1FDAC254" and perhaps as "GSSAPI"+blah.

Ok.  "GSSAPI" is only for Kerberos V5, so I think the GSS-API variant of
SCRAM would only be reachable as GS2-FOOBAR.

>> If the same name is used, the protocol specification better be consistent.
>
> The name would be different. A library's two implementations would be
> able to share the implementation (except syntax generation and
> parsing).
>
> Bt the protocol specification still has to be exactly consistent, so
> the implementation sharing works.

I think this requires that the relevant text needs to be exactly the
same in both documents.  I don't have a problem with that, although it
complicates updating the documents since they will forever be coupled
together.

>> If two different names are used, there will be no interop: SCRAM
>> implemented directly in SASL will not talk to SCRAM implemented in
>> GSS-API, and consequently in SASL via GS2. Even though it is the
>> same protocol beneath. Do you think that is acceptable?
>
> I think so.
>
> If you've implemented GSS-API SCRAM and want to implement SASL, doing
> SASL SCRAM will just be a few straight-line functions (1-4 lines, no
> if/when/while) so I don't think there'll be a significant number of
> SASL implementations that support "GS2-1ADF1FDAC254" without
> supporting "SCRAM".

I wonder whether this will fly through IESG review.  It sounds like a
bad interop situation to me.  However, maybe some careful wording about
this can mitigate it.

Ok, so it seems this approach may at least be considered.  The bigger
question is whether we can get consensus around it.

/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 n16L3NPT066918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 14:03:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16L3NZb066917; Fri, 6 Feb 2009 14:03:23 -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 n16L3LOs066911 for <[e-mail]>; Fri, 6 Feb 2009 14:03:22 -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 43DF34AC68; Fri,  6 Feb 2009 22:03:21 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1233954200-9030-1/6/132 (5 recipients); Fri, 6 Feb 2009 22:03:20 +0100
Message-Id: <aeJsQreLcQ7zjGbJ3+gvhQ.md5@lochnagar>
Date: Fri, 6 Feb 2009 22:04:13 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Simon Josefsson <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[e-mail]> <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar> <[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>

Simon Josefsson writes:
> Arnt Gulbrandsen <[e-mail]> writes:
>> As an alternative, might I suggest adding entirely separate, but 
>> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship 
>> as far as protocol goes, but intentionally similar enough that 
>> libraries which implement both can refactor the code (parsing etc. 
>> excepted).
>
> Which SASL mechanism name should be used for these two different protocols?

"SCRAM" for SCRAM. I presume the GSS-API one would be reachable in SASL 
both as "GS2-1FAD1FDAC254" and perhaps as "GSSAPI"+blah.

> If the same name is used, the protocol specification better be consistent.

The name would be different. A library's two implementations would be 
able to share the implementation (except syntax generation and 
parsing).

Bt the protocol specification still has to be exactly consistent, so the 
implementation sharing works.

> If two different names are used, there will be no interop: SCRAM 
> implemented directly in SASL will not talk to SCRAM implemented in 
> GSS-API, and consequently in SASL via GS2. Even though it is the same 
> protocol beneath. Do you think that is acceptable?

I think so.

If you've implemented GSS-API SCRAM and want to implement SASL, doing 
SASL SCRAM will just be a few straight-line functions (1-4 lines, no 
if/when/while) so I don't think there'll be a significant number of 
SASL implementations that support "GS2-1ADF1FDAC254" without supporting 
"SCRAM".

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 n16KnaIf066277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 13:49:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16Knafj066276; Fri, 6 Feb 2009 13:49: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-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16KnY7B066270 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 6 Feb 2009 13:49:35 -0700 (MST) (envelope-from [e-mail])
Received: from 62-50-194-107.client.stsn.net ([62.50.194.107] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LVXdk-0004yB-Nn; Fri, 06 Feb 2009 21:49:33 +0100
From: Simon Josefsson <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-gs2-00.txt]
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090206:[e-mail]::Lax4O/u6O4bxtuYR:5Vwa
X-Hashcash: 1:22:090206:[e-mail]::YiOYNWgGc4GdGN+b:DTSq
X-Hashcash: 1:22:090206:[e-mail]::YfU1triIPhO9QvUO:Wklf
Date: Fri, 06 Feb 2009 21:49:25 +0100
In-Reply-To: <[e-mail]> (Hallvard B. Furuseth's message of "Fri, 6 Feb 2009 20:03:41 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED,TVD_RCVD_IP autolearn=no version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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:

> Alexey Melnikov writes:
>> This is a preview of how SCRAM as GS2 document might look like. I think 
>> it should have enough details for people to make a decision between 
>> stand-alone SCRAM and SCRAM as GS2 (or to raise questions that should be 
>> sufficient to make such choice.)
>
> I don't understand.  This is a GS2-* mechanism sending text messages,
> but [GS2] section 4.1 says GS2-* messages start with a binary integer.

I believe the idea was that if we get consensus to describe SCRAM as a
GSS-API mechanism, the GS2 wire syntax will need to change so that
SCRAM-under-GS2 will be a text protocol.

If SCRAM will not be defined as a GSS-API mechanism, and thus
implemented in SASL via GS2, I don't see a need to revise the wire
syntax of GS2.  GS2 can then remain a binary protocol.

I haven't updated the GS2 document pending that the discussion around
SCRAM to settle down.  If someone believes that anything could or should
be done about GS2 until SCRAM is resolved, please tell me.

/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 n16KhrQY066084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 13:43:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16KhrAM066083; Fri, 6 Feb 2009 13:43:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16KhpMa066075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 6 Feb 2009 13:43:52 -0700 (MST) (envelope-from [e-mail])
Received: from 62-50-194-107.client.stsn.net ([62.50.194.107] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LVXYC-0004y3-BR; Fri, 06 Feb 2009 21:43:49 +0100
From: Simon Josefsson <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[e-mail]> <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090206:[e-mail]::GwsR1P4tSzyK9ePI:0gb0
X-Hashcash: 1:22:090206:[e-mail]::1qkYwEMOh1jSNC0j:2Swz
X-Hashcash: 1:22:090206:[e-mail]::YY+APLzDogP5WyZP:77d0
X-Hashcash: 1:22:090206:[e-mail]::JjK4w0bzNy8ERJWc:LuWg
Date: Fri, 06 Feb 2009 21:43:39 +0100
In-Reply-To: <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar> (Arnt Gulbrandsen's message of "Fri, 6 Feb 2009 21:27:15 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED,TVD_RCVD_IP autolearn=no version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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>

Arnt Gulbrandsen <[e-mail]> writes:

>> If people are allergic to seeing the terms GSS-API in a document
>> about SCRAM, SCRAM could be described two times:
>>
>> A) SCRAM as a SASL mechanism
>>
>> B) SCRAM as a GSS-API mechanism
>
> That's what you keep saying, and I keep being thinking that whatever
> you say, it'll bloat the description of SCRAM in the RFC and/or
> complicate SCRAM, and thereby make it harder for J. Random CRAM
> Implementer to write a SCRAM implementation. Alexey's draft this week
> did not change my mind.
>
> As an alternative, might I suggest adding entirely separate, but
> intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as
> far as protocol goes, but intentionally similar enough that libraries
> which implement both can refactor the code (parsing etc. excepted).

Which SASL mechanism name should be used for these two different
protocols?

If the same name is used, the protocol specification better be
consistent.  The best way to assure that is to only have one
specification.  If there are two specifications, and they do not
describe exactly the same protocol, there will be interop problems.

If two different names are used, there will be no interop: SCRAM
implemented directly in SASL will not talk to SCRAM implemented in
GSS-API, and consequently in SASL via GS2.  Even though it is the same
protocol beneath.  Do you think that is acceptable?

/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 n16KQZCl065121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 13:26:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16KQZTe065120; Fri, 6 Feb 2009 13:26:35 -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 n16KQOVb065110 for <[e-mail]>; Fri, 6 Feb 2009 13:26:35 -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 A79064AC50; Fri,  6 Feb 2009 21:26:23 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1233951982-9030-1/6/131 (5 recipients); Fri, 6 Feb 2009 21:26:22 +0100
Message-Id: <7F9FLVfcSZsm6tJPBjND1g.md5@lochnagar>
Date: Fri, 6 Feb 2009 21:27:15 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Simon Josefsson <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[e-mail]>, Nicolas Williams <[e-mail]>, SASL WG <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> <[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>

Simon Josefsson answers me:
>> I understand that others want one mechanism in both GS2 and SASL. 
>> Given that desire, SCRAM-as-GS2 makes perfect sense. But that's not 
>> my desire.
>
> I sense some confusion here.

I confess I didn't pay much attention when the benefits of SCRAM-as-GS2 
were explained. As I said, GS2 doesn't really interest me.

That isn't relevant to my arguments against SCRAM-as-GS2.

> ...
>
> If people are allergic to seeing the terms GSS-API in a document about 
> SCRAM, SCRAM could be described two times:
>
> A) SCRAM as a SASL mechanism
>
> B) SCRAM as a GSS-API mechanism

That's what you keep saying, and I keep being thinking that whatever you 
say, it'll bloat the description of SCRAM in the RFC and/or complicate 
SCRAM, and thereby make it harder for J. Random CRAM Implementer to 
write a SCRAM implementation. Alexey's draft this week did not change 
my mind.

As an alternative, might I suggest adding entirely separate, but 
intentionally parallel, SCRAMs in GSS-API and SASL? No relationship as 
far as protocol goes, but intentionally similar enough that libraries 
which implement both can refactor the code (parsing etc. excepted).

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 n16J3uKW060708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 12:03:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16J3uX4060707; Fri, 6 Feb 2009 12:03:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16J3h7P060690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 6 Feb 2009 12:03:55 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LVVzK-0006fh-GV; Fri, 06 Feb 2009 20:03:42 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx1.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LVVzK-0000Ub-79; Fri, 06 Feb 2009 20:03:42 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LVVzJ-0007hV-SR; Fri, 06 Feb 2009 20:03:41 +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: Fri, 6 Feb 2009 20:03:41 +0100
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-gs2-00.txt]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 318B83EC7F5A1E900B89BA9585E118607A5A6DBC
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1367 max/h 8 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>

Alexey Melnikov writes:
> This is a preview of how SCRAM as GS2 document might look like. I think 
> it should have enough details for people to make a decision between 
> stand-alone SCRAM and SCRAM as GS2 (or to raise questions that should be 
> sufficient to make such choice.)

I don't understand.  This is a GS2-* mechanism sending text messages,
but [GS2] section 4.1 says GS2-* messages start with a binary integer.

-- 
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 n16IV1UD058936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 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 n16IV126058935; Fri, 6 Feb 2009 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 yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16IUmvM058904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 6 Feb 2009 11:31:00 -0700 (MST) (envelope-from [e-mail])
Received: from 62-50-199-254.client.stsn.net ([62.50.199.254] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LVVTR-0004wa-5a; Fri, 06 Feb 2009 19:30:45 +0100
From: Simon Josefsson <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090206:[e-mail]::s9ITuGW9Eb337qGB:5hbU
X-Hashcash: 1:22:090206:[e-mail]::bcttWcUqoJob3pMb:4w9A
X-Hashcash: 1:22:090206:[e-mail]::xRaDgD98no3Wj18q:VoyI
X-Hashcash: 1:22:090206:[e-mail]::Yku7FbyBf/ixLR21:LPXc
Date: Fri, 06 Feb 2009 19:30:37 +0100
In-Reply-To: <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar> (Arnt Gulbrandsen's message of "Fri, 6 Feb 2009 17:49:05 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED,TVD_RCVD_IP autolearn=no version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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>

Arnt Gulbrandsen <[e-mail]> writes:

> I understand that others want one mechanism in both GS2 and
> SASL. Given that desire, SCRAM-as-GS2 makes perfect sense. But that's
> not my desire.

I sense some confusion here.

SCRAM as a GS2 mechanism won't satisfy the crowd (me included) that
wants to use SCRAM in GSS-API.  GS2 is a _SASL_ mechanism, so it does
nothing for GSS-API applications.  What is needed is to specify SCRAM as
a GSS-API mechanism.  Then it will automatically, through GS2, become a
SASL mechanism.  The wire protocols will be close to identical.

If people are allergic to seeing the terms GSS-API in a document about
SCRAM, SCRAM could be described two times:

A) SCRAM as a SASL mechanism

B) SCRAM as a GSS-API mechanism

But we will have to be careful that A) interoperate with B) under GS2.
We could also give up and say that SCRAM-the-GSS-API-mechanism MUST
never be used via GS2.  But that prevents code re-use.

I would prefer to describe SCRAM as a GSS-API mechanism, and have it be
supported in SASL via GS2 automatically.  To cater for those that cannot
read specification that contains the term GSS-API, there could be an
informational document to describe how to implement directly in SASL
using the GS2 SASL mech name.

/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 n16Hm9dR057231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 10:48:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16Hm9jA057230; Fri, 6 Feb 2009 10:48: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 (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n16Hlwqp057222 for <[e-mail]>; Fri, 6 Feb 2009 10:48:09 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 6 Feb 2009 09:47:57 -0800 (PST)
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]; Fri, 06 Feb 2009 09:47:54 -0800 (PST)
Date: Fri, 06 Feb 2009 09:43:40 -0800 (PST)
From: [e-mail]
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
In-reply-to: "Your message dated Fri, 06 Feb 2009 17:49:05 +0100" <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
To: Arnt Gulbrandsen <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
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 Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
> >>  Nicolas Williams wrote:
> >>
> >>  >Are the two versions supposed to be the same protocol, but described
> >>  >differently?  Or are they different protocols?
> >>  >
> >>  >
> >>  The two versions are slightly different on the wire - GS2 version
> >>  requires different layout, different MIC to protect authorization
> >>  identity, etc.
> >
> > If it the same messages can't be reused to fashion a GSS mechanism
> > then I'm not interested, so count me as in favor of SCRAM-as-GS2.
> >
> > BUT, I don't understand this poll. Why are we having it as opposed a
> > poll as to how to describe SCRAM? Is it because SCRAM-as-GS2, even
> > described as a pure SASL mech, is too complicated?

> I think so.

> > If so, what are the complicating issues that make it a deal breaker
> > for others?

> I don't care _what_ they are. Let me explain.

> What I want is a replacement for digest-md5 and/or cram-md5, neither
> more nor less. GS2 is entirely irrelevant to me, EXCEPT:

> 1. Making one document define SCRAM both in GS2 and pure SASL formats
> bloats the text. I want the document to be simple, so that _everyone_
> who today has a crammd5.c can write a scram.c _as_easily_as_ it was to
> write that crammd5.c. Bloating the document with an alternate
> definition is no help. People _will_ read the other half and _will_
> spend time trying to understand it, if only to decide what part they
> should understand and implement.

> 2. If the mechanism and document are significantly complicated by the
> requirements of GS2, then that's significantly worse.

This sums up my position nicely. SCRAM is coming to the party very late indeed,
and because of that there's a pretty good chance it won't deploy. Every bit of
additional complexity in the specification increases this chance.

As such, I'm opposed to the GS2 approach unless it can be made to be as simple
or simpler than the direct approach. And from what I can tell from the two
specificaation that's not possible.

> The precise nature of the complicating issues doesn't affect either
> point. Only their existence matter.

Exactly so.

				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 n16GmRai054492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 09:48:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16GmQ30054490; Fri, 6 Feb 2009 09:48:27 -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 n16GmFEH054475 for <[e-mail]>; Fri, 6 Feb 2009 09:48:26 -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 A9A264AC68; Fri,  6 Feb 2009 17:48:13 +0100 (CET)
Received: from [e-mail] (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1233938893-9030-1/6/128 (4 recipients); Fri, 6 Feb 2009 17:48:13 +0100
Message-Id: <RpxWKTkdLWeuN+m1vAsNpg.md5@lochnagar>
Date: Fri, 6 Feb 2009 17:49:05 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Nicolas Williams writes:
> On Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
>>  Nicolas Williams wrote:
>>
>>  >Are the two versions supposed to be the same protocol, but described
>>  >differently?  Or are they different protocols?
>>  >
>>  >
>>  The two versions are slightly different on the wire - GS2 version
>>  requires different layout, different MIC to protect authorization
>>  identity, etc.
>
> If it the same messages can't be reused to fashion a GSS mechanism 
> then I'm not interested, so count me as in favor of SCRAM-as-GS2.
>
> BUT, I don't understand this poll. Why are we having it as opposed a 
> poll as to how to describe SCRAM? Is it because SCRAM-as-GS2, even 
> described as a pure SASL mech, is too complicated?

I think so.

> If so, what are the complicating issues that make it a deal breaker 
> for others?

I don't care _what_ they are. Let me explain.

What I want is a replacement for digest-md5 and/or cram-md5, neither 
more nor less. GS2 is entirely irrelevant to me, EXCEPT:

1. Making one document define SCRAM both in GS2 and pure SASL formats 
bloats the text. I want the document to be simple, so that _everyone_ 
who today has a crammd5.c can write a scram.c _as_easily_as_ it was to 
write that crammd5.c. Bloating the document with an alternate 
definition is no help. People _will_ read the other half and _will_ 
spend time trying to understand it, if only to decide what part they 
should understand and implement.

2. If the mechanism and document are significantly complicated by the 
requirements of GS2, then that's significantly worse.

The precise nature of the complicating issues doesn't affect either 
point. Only their existence matter.

I understand that others want one mechanism in both GS2 and SASL. Given 
that desire, SCRAM-as-GS2 makes perfect sense. But that's not my 
desire.

> I have the feeling that instead of listing those issues and addressing 
> them we're just giving up.

Yes... I think I gave up earlier this week, when I saw I wasn't the only 
person to be unsure of whether the two SCRAM definitions would 
interoperate (minor mistakes aside). SCRAM won't be what I want.

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 n16FVNZ3050702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 08:31:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16FVNKw050701; Fri, 6 Feb 2009 08:31:23 -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 n16FVBqe050689 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 6 Feb 2009 08:31:21 -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 n16FVAvx022524 for <[e-mail]>; Fri, 6 Feb 2009 15:31:11 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 n16FVACL026165 for <[e-mail]>; Fri, 6 Feb 2009 08:31:10 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n16FMMZI014442; Fri, 6 Feb 2009 09:22:22 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n16FMJBw014441; Fri, 6 Feb 2009 09:22:19 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 6 Feb 2009 09:22:19 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[e-mail]>
References: <[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 Fri, Feb 06, 2009 at 10:31:16AM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> 
> >Are the two versions supposed to be the same protocol, but described
> >differently?  Or are they different protocols?
> > 
> >
> The two versions are slightly different on the wire - GS2 version 
> requires different layout, different MIC to protect authorization 
> identity, etc.

If it the same messages can't be reused to fashion a GSS mechanism then
I'm not interested, so count me as in favor of SCRAM-as-GS2.

BUT, I don't understand this poll.  Why are we having it as opposed a
poll as to how to describe SCRAM?  Is it because SCRAM-as-GS2, even
described as a pure SASL mech, is too complicated?  If so, what are the
complicating issues that make it a deal breaker for others?

I have the feeling that instead of listing those issues and addressing
them we're just giving up.

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 n16AVpdo032098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 03:31:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n16AVpdd032097; Fri, 6 Feb 2009 03:31:51 -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 n16AVdHd032074 for <[e-mail]>; Fri, 6 Feb 2009 03:31:51 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.208.51] (92.40.208.51.sub.mbb.three.co.uk [92.40.208.51])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 6 Feb 2009 10:31:35 +0000
Message-ID: <[e-mail]>
Date: Fri, 06 Feb 2009 10:31:16 +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: Nicolas Williams <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]> <[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>

Nicolas Williams wrote:

>Are the two versions supposed to be the same protocol, but described
>differently?  Or are they different protocols?
>  
>
The two versions are slightly different on the wire - GS2 version 
requires different layout, different MIC to protect authorization 
identity, etc.



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 n166S87r020604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 23:28:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n166S8Nx020603; Thu, 5 Feb 2009 23:28:08 -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 n166RurI020596 for <[e-mail]>; Thu, 5 Feb 2009 23:28:06 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n166RslO012699 for <[e-mail]>; Fri, 6 Feb 2009 06:27:55 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 n166Rs3C065045 for <[e-mail]>; Thu, 5 Feb 2009 23:27:54 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n166J4Xu014218; Fri, 6 Feb 2009 00:19:04 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n166J1c7014217; Fri, 6 Feb 2009 00:19:01 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 6 Feb 2009 00:19:01 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Message-ID: <[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>

Are the two versions supposed to be the same protocol, but described
differently?  Or are they different protocols?



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 n15NPVTu003200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 16:25:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n15NPVlj003199; Thu, 5 Feb 2009 16:25:31 -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 n15NPKOR003192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Feb 2009 16:25:31 -0700 (MST) (envelope-from [e-mail])
Received: from relay10.apple.com (relay10.apple.com [17.128.113.47]) by mail-out4.apple.com (Postfix) with ESMTP id 6D009539FC70 for <[e-mail]>; Thu,  5 Feb 2009 15:25:20 -0800 (PST)
Received: from relay10.apple.com (unknown [127.0.0.1]) by relay10.apple.com (Symantec Brightmail Gateway) with ESMTP id 5CCF52805A for <[e-mail]>; Thu,  5 Feb 2009 15:25:20 -0800 (PST)
X-AuditID: 1180712f-a6165bb0000012d3-30-498b756053e0
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay10.apple.com (Apple SCV relay) with ESMTP id 4C34828051 for <[e-mail]>; Thu,  5 Feb 2009 15:25:20 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; delsp=yes; charset=us-ascii; format=flowed
Received: from nutcracker.apple.com (nutcracker.apple.com [17.202.45.101]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 05 Feb 2009 15:25:20 -0800 (PST)
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Message-id: <[e-mail]>
In-reply-to: <[e-mail]>
Cc: SASL WG <[e-mail]>
Date: Thu, 05 Feb 2009 15:25:19 -0800
References: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.1042)
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>

5 feb 2009 kl. 13:14 skrev Alexey Melnikov:

>
> Folks,
> I would like to solicit feedback from people regarding the choice
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short
> explanation of why) to the mailing list, or say if you need more
> information.

I prefer having SCRAM as a GSS-API mech since if SCRAM was a SASL mech  
we would have to create a GSS-API mech for those protocols that  
doesn't do SASL but only GSS-API.

SASL implementors (or should I say SA implementors) can avoid  the SL  
layer if they want to (as commonly done today), that would bring the  
complexity down for them.

Love




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 n15LvKW2099161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 14:57:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n15LvK0F099160; Thu, 5 Feb 2009 14:57:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from outer-planes.net (67-41-126-81.dnvr.qwest.net [67.41.126.81] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n15Lv8KL099150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Feb 2009 14:57:19 -0700 (MST) (envelope-from [e-mail])
Received: from dencfw1.jabber.com ([207.182.164.5] helo=wrk128.corp.jabber.com) by outer-planes.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <[e-mail]>) id 1LVCDY-00083m-Do for [e-mail]; Thu, 05 Feb 2009 14:57:08 -0700
Message-Id: <[e-mail]>
From: "Matthew A. Miller" <[e-mail]>
To: SASL WG <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; boundary=Apple-Mail-1112-13263696; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
Date: Thu, 5 Feb 2009 14:56:57 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam detection software, running on the system "outlands.outer-planes.lo", has identified this incoming email as possible spam.  The original message has been attached to this so you can view it (if it isn't spam) or label similar future email.  If you have any questions, see the administrator of that system for details. Content preview:  On Feb 5, 2009, at 14:14, Alexey Melnikov wrote: > > Folks, > I would like to solicit feedback from people regarding the choice > between 2 SCRAM versions: > http://tools.ietf.org/id/draft-newman-auth-scram-08.txt > and > http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt > > You can use the following URL to see changes between them: > http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt > > Please send your opinion on which version you prefer (and a short > explanation of why) to the mailing list, or say if you need more > information. > > I would like to get all answers before February 19th, please. > > Regards, > Alexey > [...]  Content analysis details:   (-1.4 points, 3.5 required) pts rule name              description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED            Passed through trusted hosts only via SMTP
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>

--Apple-Mail-1112-13263696
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Feb 5, 2009, at 14:14, Alexey Melnikov wrote:

>
> Folks,
> I would like to solicit feedback from people regarding the choice  
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short  
> explanation of why) to the mailing list, or say if you need more  
> information.
>
> I would like to get all answers before February 19th, please.
>
> Regards,
> Alexey
>


If it's a choice between one or the other, I would choose SCRAM (stand- 
alone).  For us (being my employer), everything is already SASL, but  
not GSSAPI.

If SCRAM were updated to discuss "doing SCRAM without GS2/GSSAPI",  
then I would take that.


--
Matthew A. Miller
[e-mail]





--Apple-Mail-1112-13263696
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTTCCBUkw
ggMxoAMCAQICAwQH5TANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNzA5MTIxNzE5NDdaFw0w
OTA5MTExNzE5NDdaMEoxHTAbBgNVBAMTFE1hdHRoZXcgQWFyb24gTWlsbGVyMSkwJwYJKoZIhvcN
AQkBFhpsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAJdrLNwUaJu06JTrU/9gvBEyHsmq1gRLLnvW4FYJdY8mmLgl3Nelzid1e1dbn04r6lhb
c+3ZX2C85V4vdpkp2rxL/rAweFz+0sTZGbnpUWW003Kl5rH/oeGeg674KLynGcX6T+i8DAwYWP/P
HSyoezTR8R8Ur2cHg3/iD7MlOrFpgIhc0kyWTwq8AA/7ktClw91mMDMB0JgglUquY6pBx+B+4mRG
/mTIIkyUlmsjUbA+MOHlrs3RFvEF9tQQwL1XE1SWOFsdklzcnXS2Jq5QVxBJcOXUJeUPbOAX7rfG
icHISShG8ZUEBTOopisWZ6hQJnyPr1IdvGgPc3uKmgHBA3sCAwEAAaOCAQcwggEDMAwGA1UdEwEB
/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF
RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwME
BggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEB
BCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAlBgNVHREEHjAcgRpsaW51
eHdvbGZAb3V0ZXItcGxhbmVzLm5ldDANBgkqhkiG9w0BAQUFAAOCAgEAVqN7NFRSKNrrDsds6X4n
8u0hIIPuEnMTqt9UilpZqFp5EjqOUPPB9YPcKo5uau6venpq6ryV2oBH5kId0auS2PscMfC11UKe
gwkwVIIfhUKGs2StiInY4+TB0QXakvAxRfajidjBIuWW8mIEb/psET2Mx0/wV60PdYeEgtFfcDww
r9JZuX/iOi4opQ8IyU9cK2u2hYvlp8sCYSDdAQ8PwWQAntF3XY+u3Joxr0IUh+CimpBBtObu3LQF
P9T43adVaeOPL1RU9bCoRHOtNPGMOOgmbRGnBFHlYwvVN8NUFZq7z7nxcpIZCIPdFt7imoUTDY6P
/Uo1wL/iQJLRIXd+SOYr+RPXSQzxpePRWEU/L+kU33RJZ1Fu7IMPW/vAAg5BwrER5f0cVFyxd4A1
jsv9abpoYNUhJXbtZbSiQomil6gQM2UYHdAqo9MvvT7ezJTxDY2nceKuPuEHa4S9BTEBoFVwqALL
BbQzozPjKvchAvyx6tiwD2Tf5EmWVLc8glJAT0ujtKUHo0akWAsMjQ7f/02MKOQzQIB8P0Eiw0cK
wc6Q6+B8fJrUEYPTQ9tYEcaLhVJYj8nqUOW1ZtKEneAceeJI5PD5BW2BJnfwQu33Rr1BVmSOwaib
chl62Y2sx6Ttr372FPqWQwIlJpWjAS4qDnkTBKF4cI4nq7yDZv9a5QwxggMzMIIDLwIBATCBgDB5
MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV
BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj
ZXJ0Lm9yZwIDBAflMAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTA5MDIwNTIxNTY1OFowIwYJKoZIhvcNAQkEMRYEFLwH7UeqOMNeDQwVNdeJ
m24GZWDlMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV
aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5
MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwQH5TCBkwYLKoZIhvcNAQkQAgsx
gYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3Jn
MSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBw
b3J0QGNhY2VydC5vcmcCAwQH5TANBgkqhkiG9w0BAQEFAASCAQBlS34mh3JG08GzIaoxidql1ACx
Ip5Y0Nw/XL5mbYeLHPpookPtnTF+UavlxllmvZDY/pe8OoxAwFU/7vvAB5ZKeQ9vMHaNXkkX0/0e
0U324x/6jl1lexj5nUWgnzOq7i5rS8HAWuQzDwXqQ9ecIT0IsPKKm5js0uGaKfs0uVsaJ7WJth0d
DF8/77BrJlxGY1fGt1xpJSJwoewZeWH7nP0jSwwsWniID0A4hgsaKuaK2lTM7VKP4jFmO+tipt8B
HBPBf8dUhhcDpT7Ip95xlMfq3PqSMRoXCvMLovWr6YMFg5MbA+vy10VbAwN2PU4KB7JrxUHdooEH
Xhp8X7jDyqXpAAAAAAAA

--Apple-Mail-1112-13263696--



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 n15LbEBi098177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 14:37:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n15LbE6Q098176; Thu, 5 Feb 2009 14:37:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n15Lb1If098163 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 5 Feb 2009 14:37:13 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LVBu6-0002zP-0w; Thu, 05 Feb 2009 22:36:59 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Poll: pure SCRAM versa SCRAM-as-GS2
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090205:[e-mail]::Tlc3cGq+yqJjSRGC:GxfE
X-Hashcash: 1:22:090205:[e-mail]::26JtKCP+4rxM/WCD:K8t9
Date: Thu, 05 Feb 2009 22:36:56 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 05 Feb 2009 21:14:04 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
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 <[e-mail]> writes:

> Folks,
> I would like to solicit feedback from people regarding the choice
> between 2 SCRAM versions:
> http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
> and
> http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> You can use the following URL to see changes between them:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt
>
> Please send your opinion on which version you prefer (and a short
> explanation of why) to the mailing list, or say if you need more
> information.
>
> I would like to get all answers before February 19th, please.

I would prefer a document that describe SCRAM as a GSS-API mechanism.

Such a mechanism would be usable within SASL via GS2.  It would also be
useful outside of the SASL framework.

For SASL implementers, in a SCRAM-as-GSSAPI-mechanism document, there
could be a section that describes how to implement it as a SASL
mechanism without having to understand GSS-API or GS2.

/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 n15LFG61096693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2009 14:15:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n15LFGqs096692; Thu, 5 Feb 2009 14:15:16 -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 n15LF3iN096664 for <[e-mail]>; Thu, 5 Feb 2009 14:15:15 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.224.11] (92.40.224.11.sub.mbb.three.co.uk [92.40.224.11])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 5 Feb 2009 21:15:01 +0000
Message-ID: <[e-mail]>
Date: Thu, 05 Feb 2009 21:14:04 +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: SASL WG <[e-mail]>
Subject: Poll: pure SCRAM versa SCRAM-as-GS2
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; 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>

Folks,
I would like to solicit feedback from people regarding the choice 
between 2 SCRAM versions:
 http://tools.ietf.org/id/draft-newman-auth-scram-08.txt
and
 http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt

You can use the following URL to see changes between them:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-08.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-gs2-00.txt

Please send your opinion on which version you prefer (and a short 
explanation of why) to the mailing list, or say if you need more 
information.

I would like to get all answers before February 19th, please.

Regards,
Alexey



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 n13JmGgs033537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 12:48:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13JmGv8033536; Tue, 3 Feb 2009 12:48:16 -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 n13Jm5aa033529 for <[e-mail]>; Tue, 3 Feb 2009 12:48:16 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.173] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 3 Feb 2009 19:48:03 +0000
Message-ID: <[e-mail]>
Date: Tue, 03 Feb 2009 19:47: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
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: I-D Action:draft-newman-auth-scram-gs2-00.txt]
Content-Type: multipart/mixed; boundary="------------040203000407060309040407"
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>

--------------040203000407060309040407
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This is a preview of how SCRAM as GS2 document might look like. I think 
it should have enough details for people to make a decision between 
stand-alone SCRAM and SCRAM as GS2 (or to raise questions that should be 
sufficient to make such choice.)


--------------040203000407060309040407
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-gs2-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-gs2-00.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine (Isode M-Box/14.3v2) with LMTP; Tue, 03 Feb 2009 19:44:59 +0000 (GMT)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Tue, 3 Feb 2009 19:44:59 +0000
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 477ED3A6946;
	Tue,  3 Feb 2009 11:45:03 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0)
	id 656023A68B3; Tue,  3 Feb 2009 11:45:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-newman-auth-scram-gs2-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue,  3 Feb 2009 11:45:01 -0800 (PST)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism (GS2 variant)
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-gs2-00.txt
	Pages           : 20
	Date            : 2009-02-03

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-gs2-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-gs2-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------040203000407060309040407--



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 n11DvsAW090980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 06:57:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11Dvs3c090979; Sun, 1 Feb 2009 06:57:54 -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 n11DvfUT090971 for <[e-mail]>; Sun, 1 Feb 2009 06:57:53 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.116.35] (92.40.116.35.sub.mbb.three.co.uk [92.40.116.35])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 1 Feb 2009 13:57:38 +0000
Message-ID: <[e-mail]>
Date: Sun, 01 Feb 2009 13:57:16 +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
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: I-D Action:draft-newman-auth-scram-08.txt]
Content-Type: multipart/mixed; boundary="------------070406080904030102010308"
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>

--------------070406080904030102010308
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This version doesn't address Hallvard's concern about client 
impersonalization and the order of attributes. But otherwise it should 
be ready for WGLC.

I will post SCRAM-as-GS2 version later next week.


--------------070406080904030102010308
Content-Type: message/rfc822;
 name="I-D Action:draft-newman-auth-scram-08.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-newman-auth-scram-08.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine (Isode M-Box/14.3v2) with LMTP; Sat, 31 Jan 2009 16:30:09 +0000 (GMT)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Sat, 31 Jan 2009 16:30:08 +0000
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id CCF3F28C105;
	Sat, 31 Jan 2009 08:30:03 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0)
	id B38363A6B05; Sat, 31 Jan 2009 08:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-newman-auth-scram-08.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sat, 31 Jan 2009 08:30:01 -0800 (PST)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-newman-auth-scram-08.txt
	Pages           : 18
	Date            : 2009-01-31

The secure authentication mechanism most widely deployed and used by
 Internet application protocols is the transmission of clear-text
 passwords over a channel protected by Transport Layer Security
 (TLS).  There are some significant security concerns with that
 mechanism, which could be addressed by the use of a challenge
 response authentication mechanism protected by TLS. Unfortunately,
 the challenge response mechanisms presently on the standards track
 all fail to meet requirements necessary for widespread deployment,
 and have had success only in limited use.

 This specification describes a family of authentication mechanisms
 called the Salted Challenge Response Authentication Mechanism
 (SCRAM), which addresses the security concerns and meets the
 deployability requirements. When used in combination with TLS or an
 equivalent security layer, a mechanism from this family could
 improve the status-quo for application protocol authentication and
 provide a suitable choice for a mandatory-to-implement mechanism for
 future application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-newman-auth-scram-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-newman-auth-scram-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------070406080904030102010308--