Re: SCRAM and YAP

[Nicolas Williams <[e-mail]>]

On Wed, Jan 30, 2008 at 11:08:28PM -0700, Philip Guenther wrote:
> Without channel binding _or_ security layers, the athenticated channel 
> isn't protected from takeover and arbitrary replacement, right?  The only 
> trustable fact would be the authentication itself, if that.  Seems like a 
> pointless niche to me.

It's good enough for some valid threat models.  I think we'll end up
having it.  But yeah, _I_ would always want to use channel binding to
TLS or SASL security layers, not neither.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0VFc4hL012412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 08:38:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0VFc4Kx012411; Thu, 31 Jan 2008 08:38: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.13.5/8.13.5) with ESMTP id m0VFc3Q6012403 for <[e-mail]>; Thu, 31 Jan 2008 08:38:04 -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 m0VFc3PB007475 for <[e-mail]>; Thu, 31 Jan 2008 15:38:03 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 m0VFc3tl058795 for <[e-mail]>; Thu, 31 Jan 2008 08:38:03 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0VFc31I017358; Thu, 31 Jan 2008 09:38:03 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0VFc3Tu017357; Thu, 31 Jan 2008 09:38:03 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 31 Jan 2008 09:38:03 -0600
From: Nicolas Williams <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM and YAP
Message-ID: <[e-mail]>
Mail-Followup-To: Philip Guenther <[e-mail]>, [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, Jan 30, 2008 at 11:08:28PM -0700, Philip Guenther wrote:
> Without channel binding _or_ security layers, the athenticated channel 
> isn't protected from takeover and arbitrary replacement, right?  The only 
> trustable fact would be the authentication itself, if that.  Seems like a 
> pointless niche to me.

It's good enough for some valid threat models.  I think we'll end up
having it.  But yeah, _I_ would always want to use channel binding to
TLS or SASL security layers, not neither.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0VFYALZ012148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 08:34:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0VFYAKh012147; Thu, 31 Jan 2008 08:34:10 -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.13.5/8.13.5) with ESMTP id m0VFY9SN012140 for <[e-mail]>; Thu, 31 Jan 2008 08:34:10 -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 m0VFY9Nw011737 for <[e-mail]>; Thu, 31 Jan 2008 15:34: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 m0VFY80t056694 for <[e-mail]>; Thu, 31 Jan 2008 08:34:09 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0VFY5EA017347; Thu, 31 Jan 2008 09:34:05 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0VFY5sm017346; Thu, 31 Jan 2008 09:34:05 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 31 Jan 2008 09:34:05 -0600
From: Nicolas Williams <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM and YAP
Message-ID: <[e-mail]>
Mail-Followup-To: Philip Guenther <[e-mail]>, [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, Jan 30, 2008 at 11:08:28PM -0700, Philip Guenther wrote:
> On Wed, 30 Jan 2008, Nicolas Williams wrote:
> ...
> >Jeff H. off-line worries that "unique channel binding" need not be good 
> >enough to replace the challenge.  I believe that it always would be, or 
> >would have to be if the "unique channel binding" be good enough to 
> >detect MITMs.  I don't have proof at this time.
> 
> To me, the definition of unique channel bindings in RFC 5056 implies it:
>          +  unique channel bindings:

To me it does as well.  Strongly implies, even.  I've not thought long
enough to decide that there's proof.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V9e88c081094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2008 02:40:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V9e8tA081092; Thu, 31 Jan 2008 02:40:08 -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.13.5/8.13.5) with ESMTP id m0V9e3an081084 for <[e-mail]>; Thu, 31 Jan 2008 02:40:04 -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 B96344AC48; Thu, 31 Jan 2008 10:40:02 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1201772401-2291-510; Thu, 31 Jan 2008 10:40:01 +0100
Message-Id: <1k1JU/[e-mail]>
Date: Thu, 31 Jan 2008 10:40:00 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: SCRAM with(out) GS2 (was Re: Holding gs2)
Cc: Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Nicolas Williams <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>
References: <[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:
> We can deal with this, and we've already agreed to, by providing two 
> descriptions of the mechanism, one without reference to the GSS-API 
> nor GS2, and one with.

That's the plan. Whether the plan is good is another question.

> The simplified GS2 option we've been discussing would make that task 
> much, much easier, and would make the design of SCRAM much simpler 
> also.

Simpler from the vantage point of most WG members. Not simpler to learn 
and to implement for the people I really care about: Those who have 
Cram-MD5 or Digest-MD5 today, and who I want to implement SCRAM.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V68YXb067290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 23:08:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0V68Ypj067289; Wed, 30 Jan 2008 23:08:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0V68Xmj067283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 30 Jan 2008 23:08:34 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m0V68lXg011276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Jan 2008 22:08:47 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1201759727; bh=Wl4XYymr/25jATI82EhZSY7VSS48ub2MEFNX O/w/XhI=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:MIME-Version: Content-Type:X-MM-Ex-RefId; b=gYC/V/83Kl3h3bDhq8vP7yaCOX7JUDW7XEdg MIhF/kDyK1+85K1g1/SX3Ocn54cYPmThTujlK5zQ0X4jD1LSw5mAOckSCKDlxD2QVfe 0LcbvLNu2EOWQtDrA4NQBs2RC0Pf8OZtAJMvN2nu5ljBMd7BPtD5kzLgOfcmGFCxZIA 0=
Received: from [192.168.0.2] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m0V69Khq001089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 22:09:22 -0800
X-DKIM: Sendmail DKIM Filter v2.2.2 fife.sendmail.com m0V69Khq001089
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1201759764; bh=Wl4XYymr/25jATI82EhZSY7VSS48ub2MEFNXO /w/XhI=; h=Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type:X-MM-Ex-RefId; b=S iWBt7c2Ut6K6WKsbqHn3trEpQbmi46zeVFLjjvs8qSLXn4XnboD726JCkjIi+zFkjvq mtadtwoI1qU50f7C8or8RJdhxMtjjkUzI3k7gHYYGKcGATHdRnLR902Tbx+SlEBGW3J pLkqSYHC/bYk/TOJccjy2ajUh558deSesO/4=
Date: Wed, 30 Jan 2008 23:08:28 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Nicolas Williams <[e-mail]>
cc: [e-mail]
Subject: Re: SCRAM and YAP
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-MM-Ex-RefId: 149371::080130220923-10933B90-77CB6FDD/0-0/0-1
Sender: [e-mail]
Precedence: 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, 30 Jan 2008, Nicolas Williams wrote:
...
> Jeff H. off-line worries that "unique channel binding" need not be good 
> enough to replace the challenge.  I believe that it always would be, or 
> would have to be if the "unique channel binding" be good enough to 
> detect MITMs.  I don't have proof at this time.

To me, the definition of unique channel bindings in RFC 5056 implies it:
          +  unique channel bindings:

             channel bindings that name a channel in a cryptographically
             secure manner and uniquely in time;

If either endpoint (or a MITM!) could force a particular channel binding 
value, then that channel binding construction wouldn't "name a channel 
<...> uniquely in time".  A construction that didn't have large enough 
nonces from each endpoint wouldn't be cryptographically secure.  So, if 
its a unique channel binding, then endpoints can neither force a value nor 
reduce the entropy to an insecure level.

Or am I misinterpreting what "cryptographically secure" means there?


> Saving a round-trip the likely-to-be-common case strikes me as good.
> (Not using TLS and channel binding while also not having security layers
> strikes me as not terribly useful, security-wise, though still something
> that should be supported.)

Without channel binding _or_ security layers, the athenticated channel 
isn't protected from takeover and arbitrary replacement, right?  The only 
trustable fact would be the authentication itself, if that.  Seems like a 
pointless niche to me.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULaIO1032965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 14:36:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0ULaIdl032964; Wed, 30 Jan 2008 14:36: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-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULaHnY032949 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 30 Jan 2008 14:36:18 -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 m0ULaHGn014581 for <[e-mail]>; Wed, 30 Jan 2008 21:36:17 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 m0ULaG8u009298 for <[e-mail]>; Wed, 30 Jan 2008 14:36:16 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0ULaGFT016960; Wed, 30 Jan 2008 15:36:16 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0ULaFs8016959; Wed, 30 Jan 2008 15:36:15 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 30 Jan 2008 15:36:15 -0600
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>
Subject: Re: SCRAM with(out) GS2 (was Re: Holding gs2)
Message-ID: <[e-mail]>
Mail-Followup-To: Jeffrey Hutzelman <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[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 Wed, Jan 30, 2008 at 04:28:19PM -0500, Jeffrey Hutzelman wrote:
> --On Wednesday, January 30, 2008 02:55:53 PM -0600 Nicolas Williams 
> <[e-mail]> wrote:
> >Frankly, the more I think about it the more I just want to get rid of
> >the security layers.  Simon?  Others?
> 
> I'm actually beginning to believe that security layers were never the right 
> answer in the first place -- all we ever really needed was channel bindings.

I've known that for a while :)

The problem is we don't get to go back in time, and it may take time to
get folks to deploy TLS libraries that make CBs available.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULSQse032377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 14:28:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0ULSQIV032376; Wed, 30 Jan 2008 14:28: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.13.5/8.13.5) with ESMTP id m0ULSNWm032368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 30 Jan 2008 14:28:25 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0ULSJCA007126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 16:28:19 -0500 (EST)
Date: Wed, 30 Jan 2008 16:28:19 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>
cc: [e-mail]
Subject: Re: SCRAM with(out) GS2 (was Re: Holding gs2)
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]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, January 30, 2008 02:55:53 PM -0600 Nicolas Williams 
<[e-mail]> wrote:

>
> On Wed, Jan 30, 2008 at 10:22:09AM -0600, Nicolas Williams wrote:
>> Thus I am strongly in favor of at least adding the channel-binding-only
>> option to GS2.  I am also leaning towards being in favor of removing
>> support for security layers and security layer negotiation from GS2 as
>> well -- that would another significant simplification.  On the latter
>> point I'd like to hear from Simon and others whether they are OK with
>> GS2 (GS3, whatever) mechanisms not providing any security layers.
>
> Frankly, the more I think about it the more I just want to get rid of
> the security layers.  Simon?  Others?

I'm actually beginning to believe that security layers were never the right 
answer in the first place -- all we ever really needed was channel bindings.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULElxp030978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 14:14:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0ULElb7030977; Wed, 30 Jan 2008 14:14:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0ULElYR030970 for <[e-mail]>; Wed, 30 Jan 2008 14:14:47 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0ULEkhT005568 for <[e-mail]>; Wed, 30 Jan 2008 21:14:46 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 m0ULEkjv060292 for <[e-mail]>; Wed, 30 Jan 2008 14:14:46 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0ULEkRO016925 for <[e-mail]>; Wed, 30 Jan 2008 15:14:46 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0ULEkCx016924 for [e-mail]; Wed, 30 Jan 2008 15:14:46 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 30 Jan 2008 15:14:46 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: SCRAM and YAP
Message-ID: <[e-mail]>
Mail-Followup-To: [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>

While we're at it, if we'll not have sec layers and we'll expect the use
of TLS and channel bindings, then we might as well add a fast mode to
SCRAM where IF the channel bindings provided are of the "unique" type,
where the channel binding is used as the challenge (this what Kurt's YAP
is premised on).

Jeff H. off-line worries that "unique channel binding" need not be good
enough to replace the challenge.  I believe that it always would be, or
would have to be if the "unique channel binding" be good enough to
detect MITMs.  I don't have proof at this time.

Saving a round-trip the likely-to-be-common case strikes me as good.
(Not using TLS and channel binding while also not having security layers
strikes me as not terribly useful, security-wise, though still something
that should be supported.)

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UKu2R5029359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 13:56:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UKu2AU029358; Wed, 30 Jan 2008 13:56:02 -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.13.5/8.13.5) with ESMTP id m0UKtxoi029347 for <[e-mail]>; Wed, 30 Jan 2008 13:55:59 -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 m0UKtwJ0028709 for <[e-mail]>; Wed, 30 Jan 2008 20:55: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 m0UKtwKB046918 for <[e-mail]>; Wed, 30 Jan 2008 13:55:58 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0UKtsVw016912; Wed, 30 Jan 2008 14:55:54 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0UKtrKb016911; Wed, 30 Jan 2008 14:55:53 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 30 Jan 2008 14:55:53 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>
Subject: Re: SCRAM with(out) GS2 (was Re: Holding gs2)
Message-ID: <[e-mail]>
Mail-Followup-To: Arnt Gulbrandsen <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Jan 30, 2008 at 10:22:09AM -0600, Nicolas Williams wrote:
> Thus I am strongly in favor of at least adding the channel-binding-only
> option to GS2.  I am also leaning towards being in favor of removing
> support for security layers and security layer negotiation from GS2 as
> well -- that would another significant simplification.  On the latter
> point I'd like to hear from Simon and others whether they are OK with
> GS2 (GS3, whatever) mechanisms not providing any security layers.

Frankly, the more I think about it the more I just want to get rid of
the security layers.  Simon?  Others?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UGMHxB003802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 09:22:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UGMHZn003801; Wed, 30 Jan 2008 09:22: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.13.5/8.13.5) with ESMTP id m0UGMB7c003789 for <[e-mail]>; Wed, 30 Jan 2008 09:22:11 -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 m0UGMA65010831 for <[e-mail]>; Wed, 30 Jan 2008 16:22: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 m0UGMAjU009607 for <[e-mail]>; Wed, 30 Jan 2008 09:22:10 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0UGMA6g016638; Wed, 30 Jan 2008 10:22:10 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0UGM94C016637; Wed, 30 Jan 2008 10:22:09 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 30 Jan 2008 10:22:09 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>
Subject: Re: SCRAM with(out) GS2 (was Re: Holding gs2)
Message-ID: <[e-mail]>
Mail-Followup-To: Arnt Gulbrandsen <[e-mail]>, [e-mail], Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[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 Wed, Jan 30, 2008 at 12:21:08PM +0100, Arnt Gulbrandsen wrote:
> Chris Newman writes:
> >I would personally have no problem implementing an all-binary SCRAM 
> >regardless of how ugly the ASN.1 and binary encoding happens to be 
> >(it just requires more lines of parsing code since I have to include 
> >all the binary->text logic for debugging).
> 
> My two cents: I want SCRAM as a replacement for Digest-MD5 and to some 
> degree Cram-MD5. That may not be a good reason, but it's mine, and I 
> worry that GS2 hurts rather than helps.
> 
> As I see it, the people I want to implement SCRAM have Cram-MD5 and/or 
> (bad) Digest-MD5 implementations, and most of them don't have 
> GSS-API/GS2 implementations. For these people, basing SCRAM on GS2 
> means that they must read and understand more RFC text and their 
> implementations will be more complex. Chris has no problem with that, 
> but I fear that many people do. More text to read and understand means 
> a greater reluctance to implement, and in turn a slower pace of 
> adoption. More complexity means worse interoperation.

We can deal with this, and we've already agreed to, by providing two
descriptions of the mechanism, one without reference to the GSS-API nor
GS2, and one with.

The simplified GS2 option we've been discussing would make that task
much, much easier, and would make the design of SCRAM much simpler also.

Thus I am strongly in favor of at least adding the channel-binding-only
option to GS2.  I am also leaning towards being in favor of removing
support for security layers and security layer negotiation from GS2 as
well -- that would another significant simplification.  On the latter
point I'd like to hear from Simon and others whether they are OK with
GS2 (GS3, whatever) mechanisms not providing any security layers.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0UBTgjF080757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 04:29:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0UBTgnH080756; Wed, 30 Jan 2008 04:29:42 -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.13.5/8.13.5) with ESMTP id m0UBTcO4080748 for <[e-mail]>; Wed, 30 Jan 2008 04:29: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 491804AC23; Wed, 30 Jan 2008 12:29:35 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1201692574-2291-4; Wed, 30 Jan 2008 12:29:34 +0100
Message-Id: <[e-mail]>
Date: Wed, 30 Jan 2008 12:21:08 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: SCRAM with(out) GS2 (was Re: Holding gs2)
Cc: Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, Nicolas Williams <[e-mail]>, Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>
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>

Chris Newman writes:
> I would personally have no problem implementing an all-binary SCRAM 
> regardless of how ugly the ASN.1 and binary encoding happens to be 
> (it just requires more lines of parsing code since I have to include 
> all the binary->text logic for debugging).

My two cents: I want SCRAM as a replacement for Digest-MD5 and to some 
degree Cram-MD5. That may not be a good reason, but it's mine, and I 
worry that GS2 hurts rather than helps.

As I see it, the people I want to implement SCRAM have Cram-MD5 and/or 
(bad) Digest-MD5 implementations, and most of them don't have 
GSS-API/GS2 implementations. For these people, basing SCRAM on GS2 
means that they must read and understand more RFC text and their 
implementations will be more complex. Chris has no problem with that, 
but I fear that many people do. More text to read and understand means 
a greater reluctance to implement, and in turn a slower pace of 
adoption. More complexity means worse interoperation.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TLQCRs026784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 14:26:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TLQCLk026783; Tue, 29 Jan 2008 14:26: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-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TLQ73f026772 for <[e-mail]>; Tue, 29 Jan 2008 14:26:08 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0TLQ7sI023482 for <[e-mail]>; Tue, 29 Jan 2008 21:26:07 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 m0TLQ6Jk045045 for <[e-mail]>; Tue, 29 Jan 2008 14:26:06 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0TLQ6NC015597; Tue, 29 Jan 2008 15:26:06 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0TLQ5L5015596; Tue, 29 Jan 2008 15:26:05 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 29 Jan 2008 15:26:05 -0600
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: Holding gs2
Message-ID: <[e-mail]>
Mail-Followup-To: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, [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 Tue, Jan 29, 2008 at 12:16:36PM -0700, Chris Newman wrote:
> Speaking as a technical participant only...
> 
> As a SASL implementer, it is my current intention to not implement the 
> "security layer" feature of SASL.  If I implement GS2, my implementation 
> will always negotiate the GS2 security layer off and will use SSL/TLS 
> channel bindings if there's any reasonable way I can get that working with 
> the Mozilla/NSS library.

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

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

The only question left for me then is this: does anyone actually want
SASL security layers with any new mechanisms, or with the replacement
for "GSSAPI"?

If the answer is "noone does" then I say we scrap GS2 and do a new thing
based on GSS-API channel binding semantics and no security layers.

If the answer is "some do" (e.g., Simon), then I think we may want a
light-weight GS2 option, for use when no security layers are desired.

> However, I only plan to implement GS2 if it provides value above the GSSAPI 
> mechanism -- that means it's only worth implementing to me if there are 
> clients that support the combination of GS2, Kerberos 5 and SSL/TLS channel 
> bindings.

OK.  To be sure there exist plenty of protocols that use both, TLS and
SASL.  What doesn't necessarily exist is support for extracting channel
bindings from TLS libraries.

> I would personally have no problem implementing an all-binary SCRAM 
> regardless of how ugly the ASN.1 and binary encoding happens to be (it just 
> requires more lines of parsing code since I have to include all the 
> binary->text logic for debugging).  However, textual protocols are easier 
> to debug, easier to understand and thus easier to deploy.  I'd be concerned 
> about the real-world deployability of an all-binary SCRAM.

Well, ciphertext and MACs won't look like text...  Password-based SASL
mechs with channel binding would make relatively little use of crypto on
the wire -- just some HMACs.  So you might be able to get your wish.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0TKpuTu023068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 13:51:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0TKpula023067; Tue, 29 Jan 2008 13:51:56 -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.13.5/8.13.5) with ESMTP id m0TKpr7q023054 for <[e-mail]>; Tue, 29 Jan 2008 13:51:54 -0700 (MST) (envelope-from [e-mail])
Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0TKpr8K014838 for <[e-mail]>; Tue, 29 Jan 2008 20:51:53 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 29 Jan 2008 13:51:53 -0700 (MST)
Received: from [10.0.191.236] ([129.150.16.192]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Tue, 29 Jan 2008 13:51:47 -0700 (MST)
Date: Tue, 29 Jan 2008 12:16:36 -0700
From: Chris Newman <[e-mail]>
Subject: Re: Holding gs2
In-reply-to: <[e-mail]>
To: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

Nicolas Williams wrote on 1/28/08 9:59 -0600:
> Sam is proposing SASL mechanisms that support channel binding but not
> any security layers, which effectively changes the semantics of channel
> binding that we had assumed/concluded we wanted.  This change can
> greatly simplify the design of future SASL mechanisms, and it can
> greatly simplify the design of a SASL/GSS bridge for GSS mechanisms that
> support channel binding.

Speaking as a technical participant only...

As a SASL implementer, it is my current intention to not implement the 
"security layer" feature of SASL.  If I implement GS2, my implementation will 
always negotiate the GS2 security layer off and will use SSL/TLS channel 
bindings if there's any reasonable way I can get that working with the 
Mozilla/NSS library.

However, I only plan to implement GS2 if it provides value above the GSSAPI 
mechanism -- that means it's only worth implementing to me if there are clients 
that support the combination of GS2, Kerberos 5 and SSL/TLS channel bindings.

I would personally have no problem implementing an all-binary SCRAM regardless 
of how ugly the ASN.1 and binary encoding happens to be (it just requires more 
lines of parsing code since I have to include all the binary->text logic for 
debugging).  However, textual protocols are easier to debug, easier to 
understand and thus easier to deploy.  I'd be concerned about the real-world 
deployability of an all-binary SCRAM.

                - Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SNTPtq006665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 16:29:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SNTPfd006664; Mon, 28 Jan 2008 16: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 brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SNTOl5006657 for <[e-mail]>; Mon, 28 Jan 2008 16:29:24 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0SNTNZD023050 for <[e-mail]>; Mon, 28 Jan 2008 23:29: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 m0SNTNUB036758 for <[e-mail]>; Mon, 28 Jan 2008 16:29:23 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0SNTN37014910; Mon, 28 Jan 2008 17:29:23 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0SNTMYg014909; Mon, 28 Jan 2008 17:29:22 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 28 Jan 2008 17:29:22 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: What am I waiting on for gs2?
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, [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>

I support this change as well, modulo the what-do-we-do-about-Sam's-
comment thread.

We may still decide to make more changes to gs2.

What would gs2 with an option to support channel-binding-but-no-sec-
layers mechanisms?

I think the packet format would change from this:

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             length                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               /
      /                      GSS_Init_sec_context or                  /
      /                   GSS_Accept_sec_context token,               /
      /                     of given length                           /
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      /                              Optional GSS_Wrap token          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

to this for the initial one (and, if we want to simplify the spec, for
all of them):

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             length                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |<gss-channel-binding-in-use>[<authzid>]                        |
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      |                                                               /
      /                      GSS_Init_sec_context or                  /
      /                   GSS_Accept_sec_context token,               /
      /                     of given length                           /
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      /                              Optional GSS_Wrap token          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where, if gss-channel-binding-in-use == TRUE then <authzid> is present
and the optional GSS_Wrap token is absent on this and all subsequent
context token exchange packets.  If gss-channel-binding-in-use == FALSE
then everything is just as it used to be.

If gss-channel-binding-in-use == TRUE then the client and the server
MUST both construct the GSS-API channel bindings from the actual channel
bindings passed in by the application and the authzid as well.  Channel
binding failure is critical in the GSS-API, so if channel binding fails
then SASL authentication fails.

gss-channel-binding-in-use can be a single octet, and authzid can be
NUL-terminated UTF-8.  The packet marshalling and unmarshalling is easy
then.  And the channel bindings can be the NUL-terminated authzid in
UTF-8 with the actual channel bindings appended.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SMWKrN001701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 15:32:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SMWKBx001700; Mon, 28 Jan 2008 15:32:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SMWGLa001684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 28 Jan 2008 15:32:19 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0SMW030008185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 17:32:14 -0500 (EST)
Date: Mon, 28 Jan 2008 17:32:00 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: What am I waiting on for gs2?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[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
Sender: [e-mail]
Precedence: 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, December 20, 2007 05:52:18 PM +0100 Simon Josefsson 
<[e-mail]> wrote:

> I support the change below.  Others?

I support the addition of a security layer bit to indicate channel binding 
negotiation failed, as described in the change in question.

However, the diff you provided also makes a second change, whose effect is 
to number bits with bit '0' being the least-significant bit rather than the 
most-significant bit, as is the convention used in the RFC Series.  Please 
see ID-Checklist section 2.1 item 9, and draft-rfc-editor-rfc2223bis-08.txt 
section 3.4.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SG08eD066380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 09:00:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SG08rw066379; Mon, 28 Jan 2008 09:00:08 -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.13.5/8.13.5) with ESMTP id m0SFxwvL066313 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 28 Jan 2008 08:59:58 -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 m0SFxviH009706 for <[e-mail]>; Mon, 28 Jan 2008 15:59:57 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 m0SFxvKS028747 for <[e-mail]>; Mon, 28 Jan 2008 08:59:57 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0SFxr77014529; Mon, 28 Jan 2008 09:59:53 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0SFxq2I014528; Mon, 28 Jan 2008 09:59:52 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 28 Jan 2008 09:59:52 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: Holding gs2
Message-ID: <[e-mail]>
Mail-Followup-To: Alexey Melnikov <[e-mail]>, Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, [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, Jan 27, 2008 at 06:27:47PM +0000, Alexey Melnikov wrote:
> I consider reduction of round-trips as the main goal of GS2.

But it doesn't quite meet that goal.  It can cost an extra half
round-trip for some mechanisms, IIRC.  (If your krb5 mech initiator
implementation doesn't support PORT_READY then it can even cost you an
extra half round-trip when using krb5.)

(Of course, channel binding alone can cost you an extra half round-trip
-- think of krb5 w/o mutual authentication: to add channel binding you
must do mutual auth, which means 1 round-trip instead of half.)

However, Sam's objection is not about round-trips, but about complexity
for implementors who wish SASL mechanisms but not GSS mechanisms: the
gs2 approach forces them to implement MIC tokens.

Sam is proposing SASL mechanisms that support channel binding but not
any security layers, which effectively changes the semantics of channel
binding that we had assumed/concluded we wanted.  This change can
greatly simplify the design of future SASL mechanisms, and it can
greatly simplify the design of a SASL/GSS bridge for GSS mechanisms that
support channel binding.

> How about publishing GS2 as Experimental RFC and move it (or replace it, 
> if errors are found) to Standard Track once we have some implementation 
> experience?

We could say that the channel binding semantics that gs2 provides are
experimental...

Or we could do (2b) as I suggested, and maybe profile gs2 for simple,
channel-binding-but-no-security-layers SASL mechanisms.  Or we could
pursue the latter as a separate thing altoghether and separately
describe a SASL/GSS bridge (gs2 extensions or gs3) with the same
properties.  I haven't yet thought enough about which approach will get
us there faster.

If we agree that we don't need any new SASL mechs to provide security
layers, and that we don't care for GSS mechanisms that don't support
channel binding, then we can even abandon gs2 and go for gs3 with a much
simpler design (using GSS-API channel bindings to do the channel binding
work and to protect the authzid -- no MIC tokens needed).

> >If I recall correctly, the use-case of hybrid SASL and GSS-API
> >mechanisms was established after we decided to do GS2.

Sam and I had been wanting a SASL/GSS bridge for a long time, and we
wanted channel binding to be a primary feature.  Sam now suggests that
we selected a channel binding semantic that was too complicated.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SACNTg033614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 03:12:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SACNCo033613; Mon, 28 Jan 2008 03:12:23 -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.13.5/8.13.5) with ESMTP id m0SACMFr033605 for <[e-mail]>; Mon, 28 Jan 2008 03:12:22 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 28 Jan 2008 10:12:10 +0000
Message-ID: <[e-mail]>
Date: Sun, 27 Jan 2008 18:33:20 +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: Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: Holding 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>

Nicolas Williams wrote:

>OK, I've been thinking about this.
>
>I think we should:
>
>1) Formalize what a SASL mechanism that supports channel binding is.
>
>   This would be an update of RFC4322.
>  
>
 [...]

>2) Decide whether we want:
>
>   a) a new SASL/GSS framework which does not support security layers,
>      and which can be described in terms of GSS-API mechanisms that
>      support channel binding,
>
>   or
>
>   b) extend GS2 to do (a) but within the existing GS2 framework.
>
>      Let's say that (2b) means having a long-form GS2 message exchange
>      for some mechanisms or uses of them, and a short-form GS2 message
>      exchange for others.
>
>   c) We may also decided that we want to pursue a simple GSS-API
>      extension to always support GS2 short-form message exchanges where
>      GSS-API frameworks and mechanisms support that simple extension.
>
>      This simple extension would consist, I think, of a new req_flag,
>      GSS_C_CHANNEL_BINDING_REQ, for GSS_Init_sec_context() and two new
>      ret_flags for GSS_Init_sec_context() and GSS_Accept_sec_context().
>      The req_flag would indicate that the caller wants to know if: a)
>      channel binding is supported by the mechanism, b) this extension
>      is supported, c) whether channel binding succeeds.
>
>      When this req_flag is used and the initiator and acceptor
>      framework and mechanism support this extension then a) channel
>      binding failure does not result in context establishment failuer,
>      b) the new ret_flags are set as follows: GSS_C_CHANNEL_NOT_BOUND
>      is set if channel binding failed, else GSS_C_CHANNEL_BOUND is set.
>  
>
 [...]

>I propose that we adopt (1) and (2b) as the simplest, yet general
>solutions.
>
>New, pure SASL mechanisms that provide channel binding but no security
>layers can then be described that: a) need not be GSS-API mechanisms, b)
>can nonetheless be implemented as SASL/GS2 mechanisms, and c) sport the
>short-form message exchange.
>  
>
Agreed.

I am all in favor of (1). Regarding various (2) choices: I prefer 2b or 2c.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SACGfA033593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 03:12:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SACG90033592; Mon, 28 Jan 2008 03:12: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.13.5/8.13.5) with ESMTP id m0SACEJ6033583 for <[e-mail]>; Mon, 28 Jan 2008 03:12:14 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 28 Jan 2008 10:12:07 +0000
Message-ID: <[e-mail]>
Date: Sun, 27 Jan 2008 18:27:47 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: Holding 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>

Simon Josefsson wrote:

>Sam Hartman <[e-mail]> writes:
>  
>
>>>>>>>"Simon" == Simon Josefsson <[e-mail]> writes:
>>>>>>>              
>>>>>>>
>>    Simon> Sam Hartman <[e-mail]> writes:
>>    >> I have a question for the SASL working group.  With the
>>    >> exception of the question I brought up about optimal round
>>    Simon> I fear this would delay GS2 implementations for Kerberos
>>    Simon> V5, which would give us useful feedback on other aspects of
>>    Simon> the document.
>>    
>>
I have to admit that I share some of the concerns raised by Steve.
I think it would be nice to go through SCRAM-as-GSS-API-mechanism 
exercise before publishing GS2. However I do understand that delaying 
GS2 because of SCRAM might not be fair for people who want to try 
implement GS2.

>>Are there any implementers of SASL or Kerberos stacks who plan to delay?
>>    
>>
>I have started to implement GS2 twice to test the Kerberos V5 reduced
>round-trip mode.  The protocol kept changing, even after passing WGLC,
>so I postponed those efforts pending a stable draft.  I recently planned
>to resume work on GS2 during February, but this discussion suggests to
>me that I need to wait longer.  Publishing GS2, with the limited
>applicability for Kerberos would move my effort forward.
>
>I'd be interested in understanding how other implementers think about
>this too.
>  
>
I [still] plan to implement GS2 once it is stable. But I am unlikely to 
be quicker than you in doing that, due to other commitments.

>I don't see why having three mechanisms to do the same is problematic.
>Ok, it does lead to complexity, but supposedly the complexity is
>_required_ in order to solve some identified problem.  GS2 solves the
>identified problem of unnecessary many round-trips compared to Kerberos
>V5 via GSS-API.  If we don't consider that a valid problem, we should
>say that GS2 should not be used with Kerberos V5 at all,
>
I consider reduction of round-trips as the main goal of GS2.

>and instead say
>that users should use GSS-API for this.  That approach would take away
>all the complexity for Kerberos in GS2.  If we go this route, I would
>support delaying publication of GS2 until we have specifications of the
>GSS-API mechanisms that were designed with GS2 in mind.
>  
>
How about publishing GS2 as Experimental RFC and move it (or replace it, 
if errors are found) to Standard Track once we have some implementation 
experience?

>If I recall correctly, the use-case of hybrid SASL and GSS-API
>mechanisms was established after we decided to do GS2.
>  
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0SACBdb033576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 03:12:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0SACBbT033575; Mon, 28 Jan 2008 03:12: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.13.5/8.13.5) with ESMTP id m0SAC5s5033555 for <[e-mail]>; Mon, 28 Jan 2008 03:12:10 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 28 Jan 2008 10:12:01 +0000
Message-ID: <[e-mail]>
Date: Sun, 27 Jan 2008 18:15:22 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: What am I waiting on for 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=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Sam Hartman <[e-mail]> writes:
>  
>
>>However if the WG doesn't have consensus behind this change then it
>>should be backed out.
>>
>I support the change below.  Others?
>  
>
I support it as well.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0PFM025031723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2008 08:22:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0PFM09A031722; Fri, 25 Jan 2008 08:22:00 -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.13.5/8.13.5) with ESMTP id m0PFLxBK031715 for <[e-mail]>; Fri, 25 Jan 2008 08:22:00 -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 m0PFLxmZ013785 for <[e-mail]>; Fri, 25 Jan 2008 15:21: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 m0PFLwPW018066 for <[e-mail]>; Fri, 25 Jan 2008 08:21:58 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0PFLwhQ012744; Fri, 25 Jan 2008 09:21:58 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0PFLvbr012743; Fri, 25 Jan 2008 09:21:57 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 25 Jan 2008 09:21:57 -0600
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: Holding gs2
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

OK, I've been thinking about this.

I think we should:

1) Formalize what a SASL mechanism that supports channel binding is.

   This would be an update of RFC4322.

   SASL mechanisms that support channel binding are SASL mechanisms
   whose client and server init/step functions take the following
   additional input parameters:

    - channel binding
    - security layers to be negotiated if channel binding succeeds

   and which perform the channel binding operation as part of the
   mechanism's authentication exchanges.  The security layers selected
   will be either the regular security layers as provided through the
   traditional inputs to these functions (if channel binding fails), or
   the second set of security layers input described above (if channel
   binding succeeds).

   This should suffice as guidance for anyone designing new SASL
   mechanisms that support channel binding.

   With a minor tweak such mechanisms can also be based on what I will
   call GS3 below.


Before I go on to (2) below, note that a SASL/GSS framework for GSS-API
mechanisms that support channel binding but where the framework will NOT
support any security layers is trivial: no MIC tokens are needed,
instead the client sends its initial token and authzid, with authzid ||
channel bindings as the GSS channel bindings, and thereafter it's a
normal, framed GSS-API context token exchange.


2) Decide whether we want:

   a) a new SASL/GSS framework which does not support security layers,
      and which can be described in terms of GSS-API mechanisms that
      support channel binding,

   or

   b) extend GS2 to do (a) but within the existing GS2 framework.

      Let's say that (2b) means having a long-form GS2 message exchange
      for some mechanisms or uses of them, and a short-form GS2 message
      exchange for others.

   c) We may also decided that we want to pursue a simple GSS-API
      extension to always support GS2 short-form message exchanges where
      GSS-API frameworks and mechanisms support that simple extension.

      This simple extension would consist, I think, of a new req_flag,
      GSS_C_CHANNEL_BINDING_REQ, for GSS_Init_sec_context() and two new
      ret_flags for GSS_Init_sec_context() and GSS_Accept_sec_context().
      The req_flag would indicate that the caller wants to know if: a)
      channel binding is supported by the mechanism, b) this extension
      is supported, c) whether channel binding succeeds.

      When this req_flag is used and the initiator and acceptor
      framework and mechanism support this extension then a) channel
      binding failure does not result in context establishment failuer,
      b) the new ret_flags are set as follows: GSS_C_CHANNEL_NOT_BOUND
      is set if channel binding failed, else GSS_C_CHANNEL_BOUND is set.


Let's consider (2b).

   If the application requests no security layers in the channel binding
   failure and success cases then:

   i) channel binding failure -> mechanism failure;

   ii) because of (i) the GSS-API channel semantics will match the SASL
       mechanism's channel binding semantics, therefore GS2 can use
       GSS-API channel bindings and dispense with the MIC token
       exchanges (i.e., GS2 short-form message exchange).

   If the application requests different security layers in the channel
   binding success and failure cases then GS2 must use the long-form
   message exchange.

Let's consider (2a).

   This would look just like the GS2 short-form message exchange
   described above, but would have a different SASL mechanism name
   prefix than GS2.

Let's consider (2c).

   In this case GS2 can automatically select which of the short-form and
   long-form message exchanges to execute based on the capabilities of
   the GSS-API framework and mechanism (on both, the initiator and
   acceptor sides).


I propose that we adopt (1) and (2b) as the simplest, yet general
solutions.

New, pure SASL mechanisms that provide channel binding but no security
layers can then be described that: a) need not be GSS-API mechanisms, b)
can nonetheless be implemented as SASL/GS2 mechanisms, and c) sport the
short-form message exchange.

New, pure SASL mechanisms that provide channel binding and optional
security layers will require the GS2 long-form message exchange (with
MIC tokens) when the application wishes to use security layers in the
case of channel binding failure, but will use the short form when the
applications requests no security layers in either case.

(1) and (2a) would be OK, of course.

(1) and (2c) would be the most general solution, but I wouldn't blame
the WG for not biting!

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0MFvQPY062628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2008 08:57:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0MFvQKJ062627; Tue, 22 Jan 2008 08:57:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0MFvOpF062619 for <[e-mail]>; Tue, 22 Jan 2008 08:57:25 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0MFvOE8003969 for <[e-mail]>; Tue, 22 Jan 2008 15:57:24 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0MFvOQq036474 for <[e-mail]>; Tue, 22 Jan 2008 08:57:24 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0MFvOWo009753; Tue, 22 Jan 2008 09:57:24 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0MFvNR3009752; Tue, 22 Jan 2008 09:57:23 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 22 Jan 2008 09:57:23 -0600
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Holding gs2
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, [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, Jan 22, 2008 at 08:14:16AM -0500, Sam Hartman wrote:
> So, no I'm not convinced we know that gs2 can meet our needs.  Of
> course with my leave, we have a month before GS2 could progress
> anyway.  It would be really great if people could actually do the work
> of specifying the mechanism for GS2 during that month.
                ^^^^^^^^^^^^^^^^^^^^^

Which mechanism?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0MErI2L055523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2008 07:53:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0MErIJR055522; Tue, 22 Jan 2008 07:53:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0MErFDi055506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 22 Jan 2008 07:53:17 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m0MEr8fs006485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2008 15:53:09 +0100
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: Holding gs2
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Mon, 21 Jan 2008 18:24:48 -0500")
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080122:[e-mail]::MZgBpqgHzeJtyCR2:0wi/
X-Hashcash: 1:22:080122:[e-mail]::8LliPiDqRUtJfVdZ:Zn7s
Date: Tue, 22 Jan 2008 15:53:08 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman <[e-mail]> writes:

>>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:
>
>     Simon> Sam Hartman <[e-mail]> writes:
>     >> I have a question for the SASL working group.  With the
>     >> exception of the question I brought up about optimal round
>     Simon> I fear this would delay GS2 implementations for Kerberos
>     Simon> V5, which would give us useful feedback on other aspects of
>     Simon> the document.
>
> Are there any implementers of SASL or Kerberos stacks who plan to delay?

I have started to implement GS2 twice to test the Kerberos V5 reduced
round-trip mode.  The protocol kept changing, even after passing WGLC,
so I postponed those efforts pending a stable draft.  I recently planned
to resume work on GS2 during February, but this discussion suggests to
me that I need to wait longer.  Publishing GS2, with the limited
applicability for Kerberos would move my effort forward.

I'd be interested in understanding how other implementers think about
this too.

I don't see why having three mechanisms to do the same is problematic.
Ok, it does lead to complexity, but supposedly the complexity is
_required_ in order to solve some identified problem.  GS2 solves the
identified problem of unnecessary many round-trips compared to Kerberos
V5 via GSS-API.  If we don't consider that a valid problem, we should
say that GS2 should not be used with Kerberos V5 at all, and instead say
that users should use GSS-API for this.  That approach would take away
all the complexity for Kerberos in GS2.  If we go this route, I would
support delaying publication of GS2 until we have specifications of the
GSS-API mechanisms that were designed with GS2 in mind.

If I recall correctly, the use-case of hybrid SASL and GSS-API
mechanisms was established after we decided to do GS2.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0MDEMpx045238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jan 2008 06:14:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0MDEM65045237; Tue, 22 Jan 2008 06:14:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0MDEK2S045231 for <[e-mail]>; Tue, 22 Jan 2008 06:14:21 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2849EC400B; Tue, 22 Jan 2008 08:14:16 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Holding gs2
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 22 Jan 2008 08:14:16 -0500
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Mon, 21 Jan 2008 23:35:32 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Jeffrey" == Jeffrey Hutzelman <[e-mail]> writes:

    Jeffrey> The main drawback to this approach is that it means GS2
    Jeffrey> can be used only with GSS-API mechanisms for which such
    Jeffrey> an AS exists.  That's fine if the only mechanisms are
    Jeffrey> standards-track base mechanisms, but things start to get
    Jeffrey> hairy if we want to allow for the use of stackable
    Jeffrey> mechanisms or of privately-defined mechanisms.  Of
    Jeffrey> course, whoever defines a private mechanism could also
    Jeffrey> specify GS2's applicability to that mechanism, at least
    Jeffrey> for anyone for which it matters.
I consider this a very significant drawback.



    Jeffrey> All of that being said, it seems that maybe we're
    Jeffrey> worrying too much.  Last I knew we had an effort underway
    Jeffrey> which it was hoped would produce a non-Kerberos GS2
    Jeffrey> mechanism.  Whether that actually materializes or not, I
    Jeffrey> think we have basically worked out what it needs to look
    Jeffrey> like to work with GS2.  Do we believe that is not
    Jeffrey> sufficient to demonstrate that GS2 can successfully be


I am unconvinced we understand how to apply GS2 to mechanisms beyond
kerberos in a manner such that those mechanisms can easily be coded as
pure sasl mechanisms.  I'm concerned about unnecessary optional
exchanges and complicated control flow.

I suspect that Chris and others will not like the result if using gs2
complicates the potential control flows, adds variable round trips,
etc.


So, no I'm not convinced we know that gs2 can meet our needs.  Of
course with my leave, we have a month before GS2 could progress
anyway.  It would be really great if people could actually do the work
of specifying the mechanism for GS2 during that month.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0M4ZbVi099699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2008 21:35:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0M4ZbN9099698; Mon, 21 Jan 2008 21:35:37 -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.13.5/8.13.5) with ESMTP id m0M4ZZ36099691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 21 Jan 2008 21:35:36 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0M4ZWhu007831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2008 23:35:33 -0500 (EST)
Date: Mon, 21 Jan 2008 23:35:32 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Sam Hartman <[e-mail]>
cc: Simon Josefsson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Holding gs2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, January 21, 2008 10:00:31 PM -0600 Nicolas Williams 
<[e-mail]> wrote:

>  - additional mechanisms based on GS2 can be published as trivial RFCs
>    (requiring IESG protocol action)

I started out agreeing with Sam that limiting GS2 to Kerberos and starting 
over again with "GS3" or whatever was a bad idea, for several reasons.

However, the more I think about this, the more I think that it might not 
actually be necessary to have a fully generic bridge that can be applied to 
any mechanism.  The original goal in doing so was to make sure that it 
would be possible to use SASL not only with existing GSS-API mechanisms but 
also with any new ones that happened to come along.  Achieving that goal 
does not require universal applicability for GS2.  All that is required is 
that when a new GSS-API mechanism is produced which is intended to be used 
with GSS-API, an applicability statement is published (possibly in the same 
document as the new mechanism) which describes GS2's applicability to the 
new mechanism.

The main drawback to this approach is that it means GS2 can be used only 
with GSS-API mechanisms for which such an AS exists.  That's fine if the 
only mechanisms are standards-track base mechanisms, but things start to 
get hairy if we want to allow for the use of stackable mechanisms or of 
privately-defined mechanisms.  Of course, whoever defines a private 
mechanism could also specify GS2's applicability to that mechanism, at 
least for anyone for which it matters.



All of that being said, it seems that maybe we're worrying too much.  Last 
I knew we had an effort underway which it was hoped would produce a 
non-Kerberos GS2 mechanism.  Whether that actually materializes or not, I 
think we have basically worked out what it needs to look like to work with 
GS2.  Do we believe that is not sufficient to demonstrate that GS2 can 
successfully be applied to mechanisms beyond Kerberos?

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0M40aeN097318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2008 21:00:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0M40aW4097317; Mon, 21 Jan 2008 21:00:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0M40XfV097306 for <[e-mail]>; Mon, 21 Jan 2008 21:00:33 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0M40W3X021100 for <[e-mail]>; Tue, 22 Jan 2008 04:00: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 m0M40WA1042595 for <[e-mail]>; Mon, 21 Jan 2008 21:00:32 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0M40WjC009546; Mon, 21 Jan 2008 22:00:32 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0M40VlF009545; Mon, 21 Jan 2008 22:00:31 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 21 Jan 2008 22:00:31 -0600
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Holding gs2
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>, [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 Mon, Jan 21, 2008 at 06:24:48PM -0500, Sam Hartman wrote:
> Simon> How about a compromise: publish GS2 soon but specify that
> Simon> it is ONLY to be used with Kerberos V5, i.e., the
> Simon> GS2-QLJHGJLWNPLMQRNK mechanism.  [...]

Sam> I think this is a really bad idea.  It could get us into a situation
Sam> where we have three standards for kerberos and SASL.  Or where we have
Sam> mechanisms that you should not use with GS2 other than negotiation
Sam> mechanisms.  That seems like a bad idea to me.

Well, you opened the can when you suggested delaying publication in the
first place...  :/

I seem to recall you (and others) wishing we could achieve channel
binding [and security layer negotiation] in fewer messages, which we
could do and still have a SASL/GSS bridge if we spent the time on
suitable GSS-API extensions or if we'd abandanded the SASL/GSS bridge
idea.  Were you indirectly suggesting this when you wrote this:

Sam> >                            [...].  I just think it would be better to
Sam> > hold that document until we get a mechanism that is both a GSS and
Sam> > SASL mechanism or we conclude that doesn't work for us.

?

While I agree with the sentiment, if we have implementors who would ship
an implementation in less time than it would take us to re-design GS2,
then I think it's just too late.  There are good reasons why we went
with this design, and we were aware of the trade-offs then.  What, if
anything, has changed to warrant re-designing GS2?

If we really must then I'd offer the following compromise, similar to
Simon's:

 - update RFC4422 to add a normative description of GS2 channel binding
   semantics (actually, we should do this anyways!)

 - limit GS2 to the Kerberos V mechanism

 - additional mechanisms based on GS2 can be published as trivial RFCs
   (requiring IESG protocol action)

 - additional mechanisms with GS2 channel binding semantics but fewer
   messages can also be published, perhaps as a GS3 if we suitably
   extend the GSS-API, or else not generalized (except for the update to
   RFC4422, see above).

If we ever decide that GS2 is good enough then we can update it to say
that any GSS-API mechanism (except SPNEGO...) can be used as a GS2
mechanism without further IESG protocol action.

But first I'd like to see whether, given our AD's doubts, we have WG
consensus to do anything other than forward GS2 to the IESG as is.
Then, if we decide to not forward it as it, we can see if we have
consensus for Sam's approach or Simon's, or something else.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0LNOtY2072825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2008 16:24:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0LNOtJK072824; Mon, 21 Jan 2008 16:24:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0LNOppO072814 for <[e-mail]>; Mon, 21 Jan 2008 16:24:53 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 246E44817; Mon, 21 Jan 2008 18:24:48 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: Holding gs2
References: <[e-mail]> <[e-mail]>
Date: Mon, 21 Jan 2008 18:24:48 -0500
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Sat, 19 Jan 2008 15:28:13 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:

    Simon> Sam Hartman <[e-mail]> writes:
    >> I have a question for the SASL working group.  With the
    >> exception of the question I brought up about optimal round
    Simon> I fear this would delay GS2 implementations for Kerberos
    Simon> V5, which would give us useful feedback on other aspects of
    Simon> the document.

Are there any implementers of SASL or Kerberos stacks who plan to delay?

    Simon> How about a compromise: publish GS2 soon but specify that
    Simon> it is ONLY to be used with Kerberos V5, i.e., the
    Simon> GS2-QLJHGJLWNPLMQRNK mechanism.  This will lead to
    Simon> implementation experience for this particular use of GS2,
    Simon> while making it possible to make changes that are relevant
    Simon> for non-Kerberos mechanisms, when such experience has
    Simon> established itself.

I think this is a really bad idea.  It could get us into a situation
where we have three standards for kerberos and SASL.  Or where we have
mechanisms that you should not use with GS2 other than negotiation
mechanisms.  That seems like a bad idea to me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0JEe9Xs033185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 07:40:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0JEe9Cl033184; Sat, 19 Jan 2008 07:40:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0JEe5Rn033174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 19 Jan 2008 07:40:08 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m0JEdsJZ016291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 15:39:57 +0100
From: Simon Josefsson <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: IETF70 SASL summary
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080119:[e-mail]::n9S/09jc2AB5qnwJ:3evX
X-Hashcash: 1:22:080119:[e-mail]::bJG081sXgQPCEdHt:Dl1s
Date: Sat, 19 Jan 2008 15:39:53 +0100
In-Reply-To: <[e-mail]> (Tom Yu's message of "Thu, 03 Jan 2008 18:41:14 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu <[e-mail]> writes:

>>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:
>
> Simon> Tom Yu <[e-mail]> writes:
>>> Simon Josefsson has indicated he is not interested in purusing his
>>> password-based mech draft at this time
>
> Simon> Just to clarify: I will pursue the draft (implementing it now, the draft
> Simon> will change a lot), but due to lack of interest (I haven't seen any
> Simon> feedback), it won't include the SASL/GS2 mappings.  The document will be
> Simon> a strict password-based GSS-API mechanism.
>
> Do you intend for the SASL WG to continue considering this document,
> or are you going to pursue it in Kitten rather than in SASL?  Also, I
> believe that during SASL charter discussion, we had agreement that the
> WG will attempt to produce a password-based mechanism that is a valid
> GS2 mechanism, so there is interest in a mechanism that is valid both
> as a GSS-API mechanism and as a SASL mechanism.
>
> If you do intend for it to continue to be considered within SASL, I
> would like to make sure that people have adequately considered it in
> the context of our password-based mech charter goal.

I did intend for my proposal to be considered by the SASL WG, see:

http://article.gmane.org/gmane.ietf.kitten/1291

Whether the work is actually done in the SASL WG, the Kitten WG, or
elsewhere, seems less important to me.  Alas, I haven't had much time to
improve the document since my initial post of it, though.

What I need is a secure GSS-API mechanism for password authentication;
using it under GS2 was a secondary goal.

I may have missed them, but are there any other concrete proposals for
password based GSS-API mechanisms?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0JESWjC032160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 07:28:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0JESWZK032159; Sat, 19 Jan 2008 07:28:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0JESSQY032149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 19 Jan 2008 07:28:31 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m0JESD76014919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2008 15:28:17 +0100
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: Holding gs2
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080119:[e-mail]::CPK6J+7T+i8bmheH:40qZ
X-Hashcash: 1:22:080119:[e-mail]::t4532ivw9oEk5qZ6:IjQN
Date: Sat, 19 Jan 2008 15:28:13 +0100
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Wed, 16 Jan 2008 19:18:48 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman <[e-mail]> writes:

> I have a question for the SASL working group.  With the exception of
> the question I brought up about optimal round trips, GS2 seems ready
> to last call.
>
>
> However I'd like to ask the WG to consider whether it really wants to send GS2 on its way now.
>
> I think it may be better to hold GS2 until we get experience with a
> SASL+GSS mechanism.  I'd hate for that effort to fail because we are
> unable to make some small change in GS2.
>
> If the WG believes that sending GS2 on its way now is the best thing
> to do I (or my successor) can send it to ietf last call after we
> finish discussion on my comments.  I just think it would be better to
> hold that document until we get a mechanism that is both a GSS and
> SASL mechanism or we conclude that doesn't work for us.

I fear this would delay GS2 implementations for Kerberos V5, which would
give us useful feedback on other aspects of the document.

How about a compromise: publish GS2 soon but specify that it is ONLY to
be used with Kerberos V5, i.e., the GS2-QLJHGJLWNPLMQRNK mechanism.
This will lead to implementation experience for this particular use of
GS2, while making it possible to make changes that are relevant for
non-Kerberos mechanisms, when such experience has established itself.

The GS2 document could later be updated with the fixes needed for
non-Kerberos V5 mechanisms, and say that a bunch of other SASL
mechanisms names are now permitted.

I think how GS2 will work with Kerberos V5 is well understood, since it
has been the only practical example to think about when we designed GS2.
So if there mistakes relevant to Kerberos V5 in GS2, I don't believe we
can hope to find them without implementation feedback at this stage.

The only problem would be if we need to change something in GS2 that
would affect how Kerberos V5 exchanges behave.  That would be
interesting.  If that happens, as a worst scenario, it is always
possible to call the revised protocol GS3 and have it say that if you
use Kerberos V5, you need to use GS2-* instead.  Unless there are
security issues in GS2, then we would need to revise it anyway, in
possible backwards incompatible ways.

What do people think?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H0IoiB038624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2008 17:18:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0H0Io8s038623; Wed, 16 Jan 2008 17:18:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0H0InVR038616 for <[e-mail]>; Wed, 16 Jan 2008 17:18:50 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 998D84817; Wed, 16 Jan 2008 19:18:48 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: Holding gs2
Date: Wed, 16 Jan 2008 19:18:48 -0500
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a question for the SASL working group.  With the exception of
the question I brought up about optimal round trips, GS2 seems ready
to last call.


However I'd like to ask the WG to consider whether it really wants to send GS2 on its way now.

I think it may be better to hold GS2 until we get experience with a
SASL+GSS mechanism.  I'd hate for that effort to fail because we are
unable to make some small change in GS2.

If the WG believes that sending GS2 on its way now is the best thing
to do I (or my successor) can send it to ietf last call after we
finish discussion on my comments.  I just think it would be better to
hold that document until we get a mechanism that is both a GSS and
SASL mechanism or we conclude that doesn't work for us.

--Sam



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0465s14014093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 23:05:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m0465sRr014092; Thu, 3 Jan 2008 23:05:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m0465q8G014085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 3 Jan 2008 23:05:53 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m0465oKE017513 for <[e-mail]>; Fri, 4 Jan 2008 01:05:51 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m0465o4c003861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Fri, 4 Jan 2008 01:05:50 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m0465oWI014441; Fri, 4 Jan 2008 01:05:50 -0500 (EST)
To: [e-mail]
Subject: draft SASL IETF70 minutes uploaded
From: Tom Yu <[e-mail]>
Date: Fri, 04 Jan 2008 01:05:50 -0500
Message-ID: <[e-mail]>
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've uploaded draft SASL WG session minutes for IETF70 to the meeting
materials site.  Please reply with corrections, etc.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03NfISP090149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 16:41:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03NfI3h090148; Thu, 3 Jan 2008 16:41:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03NfGTg090141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 3 Jan 2008 16:41:17 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m03NfFqq010345; Thu, 3 Jan 2008 18:41:15 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m03NfELE022279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2008 18:41:15 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m03NfEvw013101; Thu, 3 Jan 2008 18:41:14 -0500 (EST)
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: IETF70 SASL summary
References: <[e-mail]> <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Thu, 03 Jan 2008 18:41:14 -0500
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Fri, 07 Dec 2007 12:52:07 +0100")
Message-ID: <[e-mail]>
Lines: 23
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:

Simon> Tom Yu <[e-mail]> writes:
>> Simon Josefsson has indicated he is not interested in purusing his
>> password-based mech draft at this time

Simon> Just to clarify: I will pursue the draft (implementing it now, the draft
Simon> will change a lot), but due to lack of interest (I haven't seen any
Simon> feedback), it won't include the SASL/GS2 mappings.  The document will be
Simon> a strict password-based GSS-API mechanism.

Do you intend for the SASL WG to continue considering this document,
or are you going to pursue it in Kitten rather than in SASL?  Also, I
believe that during SASL charter discussion, we had agreement that the
WG will attempt to produce a password-based mechanism that is a valid
GS2 mechanism, so there is interest in a mechanism that is valid both
as a GSS-API mechanism and as a SASL mechanism.

If you do intend for it to continue to be considered within SASL, I
would like to make sure that people have adequately considered it in
the context of our password-based mech charter goal.

---Tom



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03NCsMC088436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2008 16:12:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m03NCsY9088435; Thu, 3 Jan 2008 16:12:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m03NCqqx088425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 3 Jan 2008 16:12:53 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m03NCmfH029465; Thu, 3 Jan 2008 18:12:49 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m03NClKP017896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2008 18:12:48 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m03NClDN012962; Thu, 3 Jan 2008 18:12:47 -0500 (EST)
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: new milestones for charter update
References: <[e-mail]> <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Thu, 03 Jan 2008 18:12:47 -0500
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 20 Dec 2007 20:43:33 +0000")
Message-ID: <[e-mail]>
Lines: 12
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Alexey" == Alexey Melnikov <[e-mail]> writes:

Alexey> But I would really like to have more or less solid SCRAM
Alexey> document before we obsolete DIGEST-MD5.

How solid does the DIGEST-MD5 successor document need to be?  Does
anyone else believe that we should delay publication of
digest-to-historic until we have a solid document for the DIGEST-MD5
successor?  I would prefer to not introduce more dependencies than
absolutely necessary.

---Tom