Re: Updated SASL And Channel Binding document (-03)

[Kurt Zeilenga <[e-mail]>]

On Apr 29, 2009, at 12:29 PM, Kurt Zeilenga wrote:

>
>
> Simon wrote:
>
>> There is no interface
>> for querying for the advertised mechanisms, since no SASL mechanism
>> before has needed this.
>
> Right.  The SASL [RFC4422] design is that introduction of any  
> mechanism may place new requirements on those trying to abstract  
> away the differences between mechanisms to application level  
> protocol implementations.
>
> While SCRAM and GS2 (and YAP) introduce such new requirements, I  
> still buy into that RFC 4422 needs to be changed to support these  
> new requirements.  And I certainly don't buy into the idea that what  
> we say today about "CB in SASL" will be generally "good enough" for  
> all future mechanisms.

s/still buy/still don't/, of course.  :-)
>
>
> I am still of the mind that discussion of these new requirements  
> need only be discussed in the mechanism specifications that  
> introduce them.  It will be hard enough to reach consensus with  
> respect to a single mechanism (or family of mechanisms) than to  
> attempt to reach consensus for all future mechanisms.
>
> -- Kurt
>


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TMOQhP068311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 15:24:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3TMOQMc068310; Wed, 29 Apr 2009 15:24:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TMOPV0068304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Apr 2009 15:24:25 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n3TMOMlD068974; Wed, 29 Apr 2009 22:24:22 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Wed, 29 Apr 2009 15:24:21 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: 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 Apr 29, 2009, at 12:29 PM, Kurt Zeilenga wrote:

>
>
> Simon wrote:
>
>> There is no interface
>> for querying for the advertised mechanisms, since no SASL mechanism
>> before has needed this.
>
> Right.  The SASL [RFC4422] design is that introduction of any  
> mechanism may place new requirements on those trying to abstract  
> away the differences between mechanisms to application level  
> protocol implementations.
>
> While SCRAM and GS2 (and YAP) introduce such new requirements, I  
> still buy into that RFC 4422 needs to be changed to support these  
> new requirements.  And I certainly don't buy into the idea that what  
> we say today about "CB in SASL" will be generally "good enough" for  
> all future mechanisms.

s/still buy/still don't/, of course.  :-)
>
>
> I am still of the mind that discussion of these new requirements  
> need only be discussed in the mechanism specifications that  
> introduce them.  It will be hard enough to reach consensus with  
> respect to a single mechanism (or family of mechanisms) than to  
> attempt to reach consensus for all future mechanisms.
>
> -- Kurt
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TJU9PW054496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 12:30:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3TJU9xN054495; Wed, 29 Apr 2009 12:30:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TJTwaX054477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Apr 2009 12:30:08 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n3TJTqPu015084; Wed, 29 Apr 2009 19:29:53 GMT (envelope-from [e-mail])
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Wed, 29 Apr 2009 12:29:52 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: 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 wrote:

> There is no interface
> for querying for the advertised mechanisms, since no SASL mechanism
> before has needed this.

Right.  The SASL [RFC4422] design is that introduction of any  
mechanism may place new requirements on those trying to abstract away  
the differences between mechanisms to application level protocol  
implementations.

While SCRAM and GS2 (and YAP) introduce such new requirements, I still  
buy into that RFC 4422 needs to be changed to support these new  
requirements.  And I certainly don't buy into the idea that what we  
say today about "CB in SASL" will be generally "good enough" for all  
future mechanisms.

I am still of the mind that discussion of these new requirements need  
only be discussed in the mechanism specifications that introduce  
them.  It will be hard enough to reach consensus with respect to a  
single mechanism (or family of mechanisms) than to attempt to reach  
consensus for all future mechanisms.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3THsgX7048555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 10:54:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3THsgsh048554; Wed, 29 Apr 2009 10:54:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3THsfsV048547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Apr 2009 10:54:42 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n3THsc22000734; Wed, 29 Apr 2009 17:54:39 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Comments on YAP
Date: Wed, 29 Apr 2009 10:54:38 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: 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 Apr 29, 2009, at 9:30 AM, Nicolas Williams wrote:

>
> On Wed, Apr 29, 2009 at 09:01:24AM -0700, Kurt Zeilenga wrote:
>> On Apr 21, 2009, at 1:37 PM, Nicolas Williams wrote:
>>
>>>
>>> I looked at draft-zeilenga-sasl-yap-03 when revising
>>> draft-ietf-sasl-channel-bindings.
>>
>> I just uploaded -04.  Aside from other minor changes, it adds the
>> following clarifying statement to the Introduction.
>>
>>  YAP relies on client to authenticate the server within this lower-
>> level security layer to avoid information disclosure to rogue  
>> servers.
>
> I don't think that's a good idea.  Here's why: if you're really
> authenticating the server at the lower layer then why are you using
> channel binding in YAP?

The channel binding also ensures the client lower-level and YAP end  
points are the same.

One problem in many uses of TLS in application protocols is that the  
server has no clue wether the client's user well authenticated the  
server, hence the server has to be leery of man-in-the-middle  
attacks.  By using channel bindings, the server need not be concerned  
about whether the client's user well authenticated the server as it  
can rely on the channel binding to avoid man-in-the-middle attacks.

> And if the lower layer is not authenticating a
> server name then you don't get mutual auth at all.

If the client doesn't adhere to the SHOULD, then it runs the risk of  
disclosing the portions of the credentials (e.g., the authcid).   My  
view is that client's user is more sensitive to associated risks of  
such disclosure than the server's operator, so it seems reasonable to  
me to make a recommendation that the client authenticate the server at  
the lower level.   For my uses this level of authentication is quite  
sufficient.

-- Kurt





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TGeFYf042520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 09:40:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3TGeFsS042519; Wed, 29 Apr 2009 09:40:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TGe4t5042505 for <[e-mail]>; Wed, 29 Apr 2009 09:40:15 -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 n3TGe4US027417 for <[e-mail]>; Wed, 29 Apr 2009 16:40:04 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3TGe3hE041096 for <[e-mail]>; Wed, 29 Apr 2009 10:40:04 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3TGUUJ0020781; Wed, 29 Apr 2009 11:30:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3TGUUsU020780; Wed, 29 Apr 2009 11:30:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Apr 2009 11:30:29 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on YAP
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 29, 2009 at 09:01:24AM -0700, Kurt Zeilenga wrote:
> On Apr 21, 2009, at 1:37 PM, Nicolas Williams wrote:
> 
> >
> >I looked at draft-zeilenga-sasl-yap-03 when revising
> >draft-ietf-sasl-channel-bindings.
> 
> I just uploaded -04.  Aside from other minor changes, it adds the  
> following clarifying statement to the Introduction.
> 
>   YAP relies on client to authenticate the server within this lower- 
> level security layer to avoid information disclosure to rogue servers.

I don't think that's a good idea.  Here's why: if you're really
authenticating the server at the lower layer then why are you using
channel binding in YAP?  And if the lower layer is not authenticating a
server name then you don't get mutual auth at all.

Keep in mind that by "mutual authentication" I mean, in this case, that
a message is sent by the server that proves the server knew the
credential that it needed to verify the client's YAP message.  I do NOT
mean that the server _name_ is authenticated.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TG1dYc039696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 09:01:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3TG1dal039695; Wed, 29 Apr 2009 09:01:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3TG1Sl0039674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 29 Apr 2009 09:01:38 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n3TG1O54091117; Wed, 29 Apr 2009 16:01:25 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Comments on YAP
Date: Wed, 29 Apr 2009 09:01:24 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: 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 Apr 21, 2009, at 1:37 PM, Nicolas Williams wrote:

>
> I looked at draft-zeilenga-sasl-yap-03 when revising
> draft-ietf-sasl-channel-bindings.

I just uploaded -04.  Aside from other minor changes, it adds the  
following clarifying statement to the Introduction.

   YAP relies on client to authenticate the server within this lower- 
level security layer to avoid information disclosure to rogue servers.

This clarification is relevant to your comments concerning mutual  
authentication.  While YAP doesn't directly provide for mutual  
authentication, it does (quite strongly) encourage clients  
authenticate the server at the lower level.

>
>
> Here are some comments:
>
> - YAP as a variant of SCRAM seems like a good idea:

Having such a variant of SCRAM might be a good idea... but I still  
like to pursue YAP as specified in my I-D as I think its still, on its  
own, a good idea.

I leave pursuit of such a variant of SCRAM to others.

> you can reuse the
>   SCRAM PBKDF and key management.  That means less administration, and
>   also that you could normatively refer to SCRAM for parts of YAP,  
> thus
>   making the YAP I-D smaller.

>
>
> - IMO there should be a server->client message for mutual
>   authentication (though as with SCRAM there's no server name).

YAP expects the client to authenticate the server (at the lower layer)  
prior to initiating the YAP exchange.  This ensures YAP authentication  
information, such as the autchid, is not disclosed to rogue servers.

>  The
>   following is a YAP-as-variant-of-SCRAM exchange as I imagine it:
>
>    C: p,a=nico,n=Nico,p=<ClientKey XOR
> 			    HMAC(StoredKey, "n=Nico,cb=p,a=nico,tls-unique:...")
>    S: v=HMAC(ServerKey, <client's first message>)
>    C: <empty>  (optional depending on the app protocol)
>    S: <outcome of authentication>
>
>   With this you'd save a round-trip compared to SCRAM and could  
> qualify
>   for the Standards-Track (I guess what makes YAP Experimental is the
>   lack of mutual authentication).

I don't see mutual authentication as necessarily being a requirement  
for the Standards Track, but I note YAP does provide for mutual  
authentication.

That said, I continue to think Experimental as best for now (*) for YAP.

(* I don't preclude later seeking Standard Track status, such as after  
gaining significant operational experience with it.)

>
>
> - When the client has not cached the salt and/or PBKDF iteration  
> counts
>   or the cached values are out of date the mechanism could devolve  
> into
>   SCRAM:
>
>    C: n,a=nico,n=Nico,p=<ClientKey XOR
> 			    HMAC(StoredKey, "n=Nico,cb=n,a=nico,tls-unique:...")
>    S: s=<salt>,i=<iteration-count>
>    C: n,a=nico,n=Nico,p=<ClientKey XOR ...>
>    S: v=HMAC(ServerKey, <client's second message>)
>    C: <empty>  (optional depending on the app protocol)
>    S: <outcome of authentication>
>
> - You could even have YAP be exactly like SCRAM when the given channel
>   binding type is not a unique channel binding type.
>
>
>
> Nico
> -- 
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3SEknd1033867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 07:46:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3SEknoV033866; Tue, 28 Apr 2009 07:46:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3SEkbYW033848 for <[e-mail]>; Tue, 28 Apr 2009 07:46:48 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3SEkbRd021971 for <[e-mail]>; Tue, 28 Apr 2009 14:46:37 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 n3SEkaRt017379 for <[e-mail]>; Tue, 28 Apr 2009 08:46:36 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3SETVLV020035; Tue, 28 Apr 2009 09:29:31 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3SETUJ9020034; Tue, 28 Apr 2009 09:29:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 28 Apr 2009 09:29:30 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 28, 2009 at 09:24:20AM -0400, Jeffrey Hutzelman wrote:
> However, note that while RFC4422 does not specify a means for a client to 
> discover what mechanisms are available, it _does_ specify a means for the 
> server to discover what mechanism is in use -- the client is required to 
> tell it, and SASL protocols are required to have a slot for this purpose. 
> Similarly, if we are to negotiate channel binding types, then it will be 
> necessary for the client to tell the server what CB type is in use.
> 
> Since we cannot retroactively modify all SASL applications to include a new 
> slot for this purpose, the obvious choices are to either include it as part 
> of the selected mechanism name, or require mechanisms supporting channel 
> bindings to include a slot for carrying this information.  Note that 
> channel binding data is opaque to the mechanism, and the mechanism itself 
> does _not_ need to know what CB type is in use.

I'm going with "or require mechanisms supporting channel bindings to
include a slot for carrying this information" (it's just a matter of
adding the channel binding type to the GS2 header, in the case of GS2).

> >Surely the server _app_ can list the locally available mechanisms, and
> >surely GNU SASL does _not_ yet support channel binding, and surely you
> >can add a way for the _client app_ to pass the server's mech list to the
> >framework when you add support for channel binding.  You haven't
> >explained why you couldn't do that, or how you have interfaces that are
> >sufficient for channel binding already somehow.
> 
> It is only necessary for _mechanisms_ to list the available mechanisms if 
> you have a mechanism that is going to try to protect the mechanism list 
> from downgrades (something I think is desirable, but as part of a general 
> 4422 update, not as part of adding CB to SASL), or if your implementation 
> makes it the mechanism's responsibility to select a channel binding type. 

I agree.  Simon has me somewhat confused as to what his actual objection
is here.

> In the latter case, you don't just need to know the peer's available 
> mechanisms, you need to know the locally-available CB types _and the data 
> for all of them_.

Indeed (my I-D requires this now).

> Fortunately, I believe we came to the conclusion that there is no reason 
> selecting CB type has to be done by the mechanism implementation.

Note though that it does have to be done with knowledge of each channel
binding type's sub-type (unique or not) and the mechanisms' requirements
w.r.t.  unique channel binding types.

I'm very tempted to say that all mechanisms must support non-unique
channel bindings.  That would require that YAP be at least a full
round-trip instead of exactly half a round-trip.  ("At least" because
if the app chooses a non-unique channel binding then YAP would have to
devolve into a SCRAM-like mechanism.)  Requiring that YAP be adaptable
seems desirable for other reasons (for example, you want the mutual
authentication semantics that you get from having at least one
round-trip); see my comments on YAP, a separate thread.

> (*) My POV as an operator and Nico's as an operating system vendor are 
> similar in this respect.  We both must support a variety of users of the 
> software environments we provide.  Those users may be using client software 
> we provide, or not.  They may be talking to server software we provide, or 
> not.  They may be talking to servers we operate, or not.  Thus, we cannot 
> know a priori or dictate what mechanisms or channel types they will use. 
> To us, the cross-product problem means that if we do not use a framework 
> library of some sort, we have to rebuild potentially hundreds of 
> applications when a new mechanism or channel type comes along.

+1

> Now, if you can come up with some way of _mechanically_ generating the 
> cross-product, so that it is not necessary to manually register, specify, 
> implement, and deploy every combination, we can talk.  But in the meantime, 
> SCRAM-HMAC-SHA-256-TLS-ENDPOINT is a bit long.

Right.  I'm skeptical that anyone will come up with an acceptable way
of...

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3SDOcUa028022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 06:24:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3SDOctL028021; Tue, 28 Apr 2009 06:24:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3SDOPew028011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Apr 2009 06:24:36 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3SDOKQX005056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 09:24:21 -0400 (EDT)
Date: Tue, 28 Apr 2009 09:24:20 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
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]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, April 28, 2009 12:38:17 AM -0500 Nicolas Williams 
<[e-mail]> wrote:

>> You can also use the SCRAM-TLS-ENDPOINT approach, which is what I
>> suggested.  This model works fine even if some protocol doesn't transfer
>> the list of mechanisms.  There is no requirement in RFC 4422 to transfer
>> such a list.  That why I think it is architecturally more sound to not
>> assume there is a mechanism list transfer here.  However, I also agree
>> that this is a theoretical concern, not a practical one.
>
> I actually have no problem whatsoever saying that if you must negotiate
> whether to do channel binding and which channel binding type to use then
> you must also list the server's mechanisms on the client side.
>
> Channel binding is a new feature for SASL, therefore we're free to
> impose such requirements.  We're not bound by the fact that RFC4422 does
> not mandate mechanism negotiation nor how mechanism negotiation must be
> done.

In fact, SASL protocols have to "negotiate" a mechanism somehow; that is, 
the peers must somehow agree on which mechanism to use.  Many protocols do 
this by having the server advertise a mechanism list and then letting the 
client select one, but it is also possible to require preconfiguration or 
for mechanism selection to have been done as part of some prior 
communication.

Similarly, SASL protocols using channel binding will have to "negotiate" 
its use and a channel binding type, in that they will have to agree on 
these things.  Including CB advertisements in the mechanism list insures 
that protocols which do mechanism negotiation in the usual way will also be 
able to negotiate channel binding types in the same way, and at the same 
time, which eliminates a multi-level negotiation problem that I think we 
all agree should be avoided.  SASL protocols which select mechanisms in 
some other way will have to figure out some way to select channel binding 
types as well.

However, note that while RFC4422 does not specify a means for a client to 
discover what mechanisms are available, it _does_ specify a means for the 
server to discover what mechanism is in use -- the client is required to 
tell it, and SASL protocols are required to have a slot for this purpose. 
Similarly, if we are to negotiate channel binding types, then it will be 
necessary for the client to tell the server what CB type is in use.

Since we cannot retroactively modify all SASL applications to include a new 
slot for this purpose, the obvious choices are to either include it as part 
of the selected mechanism name, or require mechanisms supporting channel 
bindings to include a slot for carrying this information.  Note that 
channel binding data is opaque to the mechanism, and the mechanism itself 
does _not_ need to know what CB type is in use.


>> I was talking about the _mechanisms_ in GNU SASL.  There is no interface
>> for querying for the advertised mechanisms, since no SASL mechanism
>> before has needed this.
>
> Surely the server _app_ can list the locally available mechanisms, and
> surely GNU SASL does _not_ yet support channel binding, and surely you
> can add a way for the _client app_ to pass the server's mech list to the
> framework when you add support for channel binding.  You haven't
> explained why you couldn't do that, or how you have interfaces that are
> sufficient for channel binding already somehow.

It is only necessary for _mechanisms_ to list the available mechanisms if 
you have a mechanism that is going to try to protect the mechanism list 
from downgrades (something I think is desirable, but as part of a general 
4422 update, not as part of adding CB to SASL), or if your implementation 
makes it the mechanism's responsibility to select a channel binding type. 
In the latter case, you don't just need to know the peer's available 
mechanisms, you need to know the locally-available CB types _and the data 
for all of them_.

Fortunately, I believe we came to the conclusion that there is no reason 
selecting CB type has to be done by the mechanism implementation.



FWIW, I find the approach of including channel types in mechanism names to 
be problematic, because it creates exactly the sort of cross-product 
explosion that SASL, by its very existence, is intended to avoid.  We 
agreed that having to separately specify, implement, and deploy every 
possible combination was not OK back when we chartered this group (really, 
before then) and took on the work of specifying a framework that would 
allow protocols and mechanisms to be defined independently.  I believe the 
principle applies equally well to mechanisms and channel binding types, 
_especially_ in a time when we have several mechanisms under development 
and when there is an ongoing effort to define channel bindings for the most 
common channel types and to encourage widespread use of channel bindings 
throughout the IETF.

Having to separately handle each combination of mechanism and channel 
binding type, and having to update everthing every time there is a new 
mechanism or channel binding type, does not scale.  It makes things hard 
for people specifying mechanisms; it makes things hard for people 
implementing SASL protocols; it makes things hard for people deploying 
these things (and especially for people who have _already deployed_ these 
things and now need to update all of their applications because a new CB 
type has appeared(*)).  It also creates unnecessary work for people 
defining new channel binding types, which means those people will not _do_ 
that work, and new CB types simply won't be available for use with SASL.



(*) My POV as an operator and Nico's as an operating system vendor are 
similar in this respect.  We both must support a variety of users of the 
software environments we provide.  Those users may be using client software 
we provide, or not.  They may be talking to server software we provide, or 
not.  They may be talking to servers we operate, or not.  Thus, we cannot 
know a priori or dictate what mechanisms or channel types they will use. 
To us, the cross-product problem means that if we do not use a framework 
library of some sort, we have to rebuild potentially hundreds of 
applications when a new mechanism or channel type comes along.



Now, if you can come up with some way of _mechanically_ generating the 
cross-product, so that it is not necessary to manually register, specify, 
implement, and deploy every combination, we can talk.  But in the meantime, 
SCRAM-HMAC-SHA-256-TLS-ENDPOINT is a bit long.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3S5m870095039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 22:48:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3S5m8F8095038; Mon, 27 Apr 2009 22:48: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-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3S5lvUQ095028 for <[e-mail]>; Mon, 27 Apr 2009 22:48:07 -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 n3S5luT2006806 for <[e-mail]>; Tue, 28 Apr 2009 05:47:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3S5luhF030341 for <[e-mail]>; Mon, 27 Apr 2009 23:47:56 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3S5cKXU019852; Tue, 28 Apr 2009 00:38:20 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3S5cHva019851; Tue, 28 Apr 2009 00:38:17 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 28 Apr 2009 00:38:17 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 27, 2009 at 11:22:22PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > But your model does not make things easier for *deployers*.
> 
> I don't see a significant difference for deployers between these two
> models.  They will need to specify which mechanism to use for
> clients/servers, and maybe install new SASL plugins in their SASL
> frameworks.

Every time a new channel binding type is registered we'll need new SASL
mechs registered for all mechs that support channel binding.  Not only
must these registrations be done with the IANA, but also every deployed
implementation needs to be updated.  And is due to the 20 character
limit on SASL mech names.  I find that unacceptable.

The only thing about any channel binding type that the apps, framework
and/or mechanism need concern themselves with is whether the channel
binding type is "unique", and that comes from the channel (meaning the
SASL apps/framework/mech don't need to know about channel binding types
a priori to know whether they are unique).

> In the first model, they will (for example) have to document that
> SCRAM-PLUS is used, and that they need to make sure
> CB-UNIQUE-TLS-ENDPOINT is advertised.

That's hardly a problem.

> In the second model, they will have to document that SCRAM-TLSENDPOINT
> should be negotiated and used.

That shouldn't be a problem, but it is, mostly because of the 20 char
mech name length limit.

> >>                                                I believe the CB-foo has
> >> an architectural wart in that RFC 4422 doesn't mandate mechanism
> >> advertisement.
> >
> > Negotiation of channel binding and channel binding type through
> > mechanism negotiation is NOT a wart.  If you don't negotiate then you
> > must agree a priori on what mechanism to use, whether to use channel
> > binding, and what channel binding types are preferred (and if you don't
> > agree then you get to try again).
> 
> You can also use the SCRAM-TLS-ENDPOINT approach, which is what I
> suggested.  This model works fine even if some protocol doesn't transfer
> the list of mechanisms.  There is no requirement in RFC 4422 to transfer
> such a list.  That why I think it is architecturally more sound to not
> assume there is a mechanism list transfer here.  However, I also agree
> that this is a theoretical concern, not a practical one.

I actually have no problem whatsoever saying that if you must negotiate
whether to do channel binding and which channel binding type to use then
you must also list the server's mechanisms on the client side.

Channel binding is a new feature for SASL, therefore we're free to
impose such requirements.  We're not bound by the fact that RFC4422 does
not mandate mechanism negotiation nor how mechanism negotiation must be
done.

> > Now, IF there are applications where the client makes a proposal and
> > then the server picks a mechanism, *then* your proposal is workable and
> > mine isn't.
> 
> Or if some protocol just mandates that a particular SASL mechanism is
> used, without advertising the entire set of supported mechanisms.  Or
> use some other negotiation mechanism that doesn't involve sending the
> entire list.

See above.  I'd say such a protocol would require revising.

> >> I don't care strongly which approach is used, so I could live with
> >> CB-foo.
> >> 
> >> I can assert that SCRAM-TLSENDPOINT etc is easier to implement than the
> >> CB-foo approach in GNU SASL, because there is no established interface
> >> for SASL mechanisms to discover the list of supported mechanisms.
> >
> > That's strange.  Because listing the server's SASL mechanisms is how
> > apps negotiate SASL mechs.  So how do GNU SASL apps deal?
> 
> I was talking about the _mechanisms_ in GNU SASL.  There is no interface
> for querying for the advertised mechanisms, since no SASL mechanism
> before has needed this.

Surely the server _app_ can list the locally available mechanisms, and
surely GNU SASL does _not_ yet support channel binding, and surely you
can add a way for the _client app_ to pass the server's mech list to the
framework when you add support for channel binding.  You haven't
explained why you couldn't do that, or how you have interfaces that are
sufficient for channel binding already somehow.

> > But you'll be needing interface changes in order to deal with channel
> > binding, so why can't one of those interface changes be that the
> > addition of a slot for the client app to communicate the server's mech
> > list to the framework?
> 
> Sure, it can.  This is why I don't feel strongly about the issue.  But
> adding the new interface is not needed with the SCRAM-TLSENDPOINT
> approach.

Alternatively new channel binding types require updating at least the
deployed frameworks.  That's a trade-off that I find unappealing.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RLMUDO068610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 14:22:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RLMU3v068609; Mon, 27 Apr 2009 14:22:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RLMSes068599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Apr 2009 14:22:29 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LyYHR-0004Xm-Fi; Mon, 27 Apr 2009 23:22:26 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090427:[e-mail]::gxiU9yellMYrGh0R:ENPO
X-Hashcash: 1:22:090427:[e-mail]::iNnSvTR33ZPcpOU3:09I+f
Date: Mon, 27 Apr 2009 23:22:22 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 27 Apr 2009 15:24:32 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, Apr 27, 2009 at 09:49:06PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > But we don't need this approach to solve any particular problems.
>> 
>> Both models solve the problem of channel binding negotiation and channel
>> binding type negotiation.
>> 
>> I see the differences as a trade-off between 1) making things easier for
>> IETF/IANA (your approach with CB-foo) or, 2) for application
>> implementers (my SCRAM-TLSENDPOINT approach).
>
> But your model does not make things easier for *deployers*.

I don't see a significant difference for deployers between these two
models.  They will need to specify which mechanism to use for
clients/servers, and maybe install new SASL plugins in their SASL
frameworks.

In the first model, they will (for example) have to document that
SCRAM-PLUS is used, and that they need to make sure
CB-UNIQUE-TLS-ENDPOINT is advertised.

In the second model, they will have to document that SCRAM-TLSENDPOINT
should be negotiated and used.

>>                                                I believe the CB-foo has
>> an architectural wart in that RFC 4422 doesn't mandate mechanism
>> advertisement.
>
> Negotiation of channel binding and channel binding type through
> mechanism negotiation is NOT a wart.  If you don't negotiate then you
> must agree a priori on what mechanism to use, whether to use channel
> binding, and what channel binding types are preferred (and if you don't
> agree then you get to try again).

You can also use the SCRAM-TLS-ENDPOINT approach, which is what I
suggested.  This model works fine even if some protocol doesn't transfer
the list of mechanisms.  There is no requirement in RFC 4422 to transfer
such a list.  That why I think it is architecturally more sound to not
assume there is a mechanism list transfer here.  However, I also agree
that this is a theoretical concern, not a practical one.

> Now, IF there are applications where the client makes a proposal and
> then the server picks a mechanism, *then* your proposal is workable and
> mine isn't.

Or if some protocol just mandates that a particular SASL mechanism is
used, without advertising the entire set of supported mechanisms.  Or
use some other negotiation mechanism that doesn't involve sending the
entire list.

>> I don't care strongly which approach is used, so I could live with
>> CB-foo.
>> 
>> I can assert that SCRAM-TLSENDPOINT etc is easier to implement than the
>> CB-foo approach in GNU SASL, because there is no established interface
>> for SASL mechanisms to discover the list of supported mechanisms.
>
> That's strange.  Because listing the server's SASL mechanisms is how
> apps negotiate SASL mechs.  So how do GNU SASL apps deal?

I was talking about the _mechanisms_ in GNU SASL.  There is no interface
for querying for the advertised mechanisms, since no SASL mechanism
before has needed this.

>> Could someone familiar with Cyrus SASL tell us whether a SASL mechanism
>> .so plugin can get the list of advertised SASL mechanisms both in client
>> mode and server mode?
>
> Oh, I see, what you mean is that there's no way for the app to tell GNU
> SASL the list of mechanism names advertised by the server.

No, I am talking about the implementation of the SASL mechanism inside a
SASL library.  I suspect GNU SASL and Cyrus SASL, and other libraries,
behave similar here.

> But you'll be needing interface changes in order to deal with channel
> binding, so why can't one of those interface changes be that the
> addition of a slot for the client app to communicate the server's mech
> list to the framework?

Sure, it can.  This is why I don't feel strongly about the issue.  But
adding the new interface is not needed with the SCRAM-TLSENDPOINT
approach.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RKYbvu065238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 13:34:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RKYbXL065237; Mon, 27 Apr 2009 13:34:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RKYCpk065217 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 27 Apr 2009 13:34:22 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3RKYBPK027362 for <[e-mail]>; Mon, 27 Apr 2009 20:34:12 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3RKYB6H039005 for <[e-mail]>; Mon, 27 Apr 2009 14:34:11 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3RKOWWI019580; Mon, 27 Apr 2009 15:24:32 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3RKOWrC019579; Mon, 27 Apr 2009 15:24:32 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 27 Apr 2009 15:24:32 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 27, 2009 at 09:49:06PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > But we don't need this approach to solve any particular problems.
> 
> Both models solve the problem of channel binding negotiation and channel
> binding type negotiation.
> 
> I see the differences as a trade-off between 1) making things easier for
> IETF/IANA (your approach with CB-foo) or, 2) for application
> implementers (my SCRAM-TLSENDPOINT approach).

But your model does not make things easier for *deployers*.

>                                                I believe the CB-foo has
> an architectural wart in that RFC 4422 doesn't mandate mechanism
> advertisement.

Negotiation of channel binding and channel binding type through
mechanism negotiation is NOT a wart.  If you don't negotiate then you
must agree a priori on what mechanism to use, whether to use channel
binding, and what channel binding types are preferred (and if you don't
agree then you get to try again).

Now, IF there are applications where the client makes a proposal and
then the server picks a mechanism, *then* your proposal is workable and
mine isn't.

> I don't care strongly which approach is used, so I could live with
> CB-foo.
> 
> I can assert that SCRAM-TLSENDPOINT etc is easier to implement than the
> CB-foo approach in GNU SASL, because there is no established interface
> for SASL mechanisms to discover the list of supported mechanisms.

That's strange.  Because listing the server's SASL mechanisms is how
apps negotiate SASL mechs.  So how do GNU SASL apps deal?

> Could someone familiar with Cyrus SASL tell us whether a SASL mechanism
> .so plugin can get the list of advertised SASL mechanisms both in client
> mode and server mode?

Oh, I see, what you mean is that there's no way for the app to tell GNU
SASL the list of mechanism names advertised by the server.  But you'll
be needing interface changes in order to deal with channel binding, so
why can't one of those interface changes be that the addition of a slot
for the client app to communicate the server's mech list to the
framework?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RJnXWu062151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 12:49:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RJnXId062150; Mon, 27 Apr 2009 12:49:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RJnI9m062128 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Apr 2009 12:49:32 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LyWpE-0003rF-UJ; Mon, 27 Apr 2009 21:49:14 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090427:[e-mail]::kJDtwJGTVwzc3yCF:5uPC
X-Hashcash: 1:22:090427:[e-mail]::U8IM5CE4ABUFuH8R:9Qic
Date: Mon, 27 Apr 2009 21:49:06 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 27 Apr 2009 10:02:59 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> But we don't need this approach to solve any particular problems.

Both models solve the problem of channel binding negotiation and channel
binding type negotiation.

I see the differences as a trade-off between 1) making things easier for
IETF/IANA (your approach with CB-foo) or, 2) for application
implementers (my SCRAM-TLSENDPOINT approach).  I believe the CB-foo has
an architectural wart in that RFC 4422 doesn't mandate mechanism
advertisement.

I don't care strongly which approach is used, so I could live with
CB-foo.

I can assert that SCRAM-TLSENDPOINT etc is easier to implement than the
CB-foo approach in GNU SASL, because there is no established interface
for SASL mechanisms to discover the list of supported mechanisms.

Could someone familiar with Cyrus SASL tell us whether a SASL mechanism
.so plugin can get the list of advertised SASL mechanisms both in client
mode and server mode?

Are there other major SASL libraries which people are familiar with, and
can check?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RFCsqa039836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 08:12:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RFCsBp039835; Mon, 27 Apr 2009 08: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 sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RFCerj039803 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 27 Apr 2009 08:12:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3RFCdvN012970 for <[e-mail]>; Mon, 27 Apr 2009 15:12:39 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 n3RFCduH013319 for <[e-mail]>; Mon, 27 Apr 2009 09:12:39 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3RF316h019424; Mon, 27 Apr 2009 10:03:01 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3RF2xPv019423; Mon, 27 Apr 2009 10:02:59 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 27 Apr 2009 10:02:59 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 27, 2009 at 10:38:38AM +0200, Simon Josefsson wrote:
> > Making that list available to *some* component that can make the choice
> > is part of the scheme.  The current text allows that to be the
> > application, the framework and/or the mechanism:
> 
> As Kurt said, RFC 4422 doesn't mandate that mechanism negotiation
> happens by sending a clear-text list of all supported mechanisms.  So
> from a design point of view, CB-* style negotiation doesn't seem
> perfect.

We can probably wordsmith it so that listing the server's available
mechanisms isn't a direct requirement, but unless there exist Internet
apps that use SASL and which don't support listing the server's
available mechanisms then I don't think we should bother.

> >> For SCRAM, you would then have these mechanisms:
> >> 
> >>    SCRAM
> >>    SCRAM-TLSUNIQUE
> >>    SCRAM-TLSENDPOINT
> >
> > N * M -> bad.
> 
> I don't see that as a serious problem here, the total number of

I do.  One problem I forgot to mention is this: channel binding types
can be added at any time, so with your scheme we'd have to add new
registrations of SCRAM, GS2, ... mechanisms for each new channel binding
type.  I'd much rather have to register only the SASL name of each
channel binding type.

But wait, it gets worse.  Not only must we go back to the SASL mech name
registry to keep the M*N registrations up to date whenever a new channel
binding type is added, we also have to update deployed SASL
applications/frameworks.

Whereas with my approach the only thing that the
application/framework/mechanism need to know about new channel binding
types is whether they are "unique" (yes, apps would still need to know
about new types of channels, but the framework and mechs wouldn't).

> mechanisms for a particular server isn't going to be huge.  This
> approach has the advantage that both the channel binding negotiation,
> and the channel binding type negotiation, happens through the same
> mechanism, and that it is obvious what is intended once the mechanism is
> chosen.

But we don't need this approach to solve any particular problems.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RAh3Gg016111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 03:43:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RAh3sD016110; Mon, 27 Apr 2009 03:43:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RAh0Td016100 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Apr 2009 03:43:02 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LyOIc-0003YS-Qp; Mon, 27 Apr 2009 12:42:59 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090427:[e-mail]::Hl0qdwVhhmiqh2dJ:efQ
X-Hashcash: 1:22:090427:[e-mail]::oQQZQPwxh7H8L9Nq:1QmJ
X-Hashcash: 1:22:090427:[e-mail]::8x+nMIstgNnyL5zj:AexD
Date: Mon, 27 Apr 2009 12:42:57 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 14 Apr 2009 11:38:49 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

>> I don't see any critical problem in allowing error tokens to be sent.
>
> I don't either.  I think we should make that a MAY.

Two people in favor, none against, and discussion has stopped.  I
incorporated the proposed text.  See http://josefsson.org/sasl-gs2/ for
updated document.

I believe this addresses all of Alexey's comments made in this thread.
If I missed some comment, please let me know.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3R8chxu005461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 01:38:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3R8chh5005460; Mon, 27 Apr 2009 01:38:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3R8cfGe005452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Apr 2009 01:38:42 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LyMMK-0003VK-3Z; Mon, 27 Apr 2009 10:38:40 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090427:[e-mail]::HzQGOiAeAOKF2RVx:1zqm
X-Hashcash: 1:22:090427:[e-mail]::6kw3ZPMHaAkKEAxf:2LKX
Date: Mon, 27 Apr 2009 10:38:38 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 22 Apr 2009 10:19:27 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Wed, Apr 22, 2009 at 11:53:35AM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
>> 
>> Thanks.  Something along these lines is needed before we can implement
>> SCRAM and GS2.
>
> Well, no, but we do need this before SCRAM and GS2 can progress, IMO.

Text to solve the same problem can also be in SCRAM and GS2, like
section 6.1 in SCRAM and my new proposed section 5.1 in GS2.  It
wouldn't be a generic solution, but will probably work in practice for
SCRAM/GS2.

>> > Changes from -02:
>> >
>> >  - added channel binding type negotiation through pseudo-mechanism names
>> >     - CB-tls-srv-endpoint
>> >     - CB-tls-unique
>> >     - If the server doesn't list any then the client assumes all channel
>> >       binding types available on the client side are also available on
>> >       the server side.  But the server SHOULD list them.
>> 
>> I'm concerned that (today) the implementation of a SASL mechanism does
>> not have easy access to the list of supported SASL mechanism exposed by
>> the server.  Thus, I'm not convinced the pseudo mechanism approach will
>> be easy to implement.
>
> Making that list available to *some* component that can make the choice
> is part of the scheme.  The current text allows that to be the
> application, the framework and/or the mechanism:

As Kurt said, RFC 4422 doesn't mandate that mechanism negotiation
happens by sending a clear-text list of all supported mechanisms.  So
from a design point of view, CB-* style negotiation doesn't seem
perfect.

>> Could we explore encoding both the channel binding negotiation and
>> channel binding type negotiation in the SASL mechanism name?
>> 
>> For SCRAM, you would then have these mechanisms:
>> 
>>    SCRAM
>>    SCRAM-TLSUNIQUE
>>    SCRAM-TLSENDPOINT
>
> N * M -> bad.

I don't see that as a serious problem here, the total number of
mechanisms for a particular server isn't going to be huge.  This
approach has the advantage that both the channel binding negotiation,
and the channel binding type negotiation, happens through the same
mechanism, and that it is obvious what is intended once the mechanism is
chosen.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3R8TLin004839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 01:29:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3R8TLvG004838; Mon, 27 Apr 2009 01:29:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3R8T8FL004818 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Apr 2009 01:29:20 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LyMD2-0003V4-Jx; Mon, 27 Apr 2009 10:29:05 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090427:[e-mail]::gCP5JEo3MdzB/tGl:0jWw
X-Hashcash: 1:22:090427:[e-mail]::3vsDICwvmNixAhRn:3IUP
X-Hashcash: 1:22:090427:[e-mail]::E/OEs+9TJzb1Mt8G:AHru
Date: Mon, 27 Apr 2009 10:29:03 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Sat, 25 Apr 2009 07:16:50 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Apr 22, 2009, at 2:53 AM, Simon Josefsson wrote:
>
>>
>> Nicolas Williams <[e-mail]> writes:
>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
>>
>> Thanks.  Something along these lines is needed before we can implement
>> SCRAM and GS2.
>
> Why?
>
> In particular, do you think it not possible (or not feasible) to
> implement SCRAM and/or GS2 without change to RFC 4422 and, if so, why?
>
> My take on SCRAM, at least, is that it's quite implementable without
> change to RFC 4422.

Yes, I had missed section 6.1 of SCRAM -12.  So SCRAM would be possible
to implement without the above document.

GS2 isn't, since there is no similar description of how channel binding
types are selected.  So GS2 needs the same text.  The same text also
seems useful in GS2 to make it more likely that native-SCRAM and
SCRAM-over-GS2 will interoperate.  Otherwise a SCRAM-over-GS2
implementation may select a different channel binding type.

However, I think SCRAM section 6.1 is under-specified -- if OpenPGP
server certificates are used, the tls-server-end-point channel binding
doesn't work.  My suggestion is to change "server certificate" into
"X.509 [PKIX] server certificate".

I have merged the text into GS2:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.html#anchor11

Comments?  Does this work?

>>> Changes from -02:
>>>
>>> - added channel binding type negotiation through pseudo-mechanism
>>> names
>>>    - CB-tls-srv-endpoint
>>>    - CB-tls-unique
>>>    - If the server doesn't list any then the client assumes all
>>> channel
>>>      binding types available on the client side are also available on
>>>      the server side.  But the server SHOULD list them.
>>
>> I'm concerned that (today) the implementation of a SASL mechanism does
>> not have easy access to the list of supported SASL mechanism exposed
>> by
>> the server.
>
> Given that mechanism negotiation is "protocol specific", this should
> not be surprising to anyone.  In fact, protocols need not even provide
> a mechanism negotiation facility.

That is a good point.  So the CB-* approach doesn't work, does it?

>> Thus, I'm not convinced the pseudo mechanism approach will
>> be easy to implement.
>
> Given that today some server implementations find it hard to limit the
> advertisement of EXTERNAL to instances where the server has associated
> an identity for the client at some lower-level, we can surmise that
> some implementations will find this pseudo mechanism approach hard to
> implement.

Right.

>> Could we explore encoding both the channel binding negotiation and
>> channel binding type negotiation in the SASL mechanism name?
>
> I just wish we'd "explore" some where other than the in the base
> specification.

I agree.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3PEH9ba051107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Apr 2009 07:17:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3PEH9rM051106; Sat, 25 Apr 2009 07:17:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3PEGvtD051092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 25 Apr 2009 07:17:08 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n3PEGp6o075274; Sat, 25 Apr 2009 14:16:52 GMT (envelope-from [e-mail])
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Sat, 25 Apr 2009 07:16:50 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_40 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: 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 Apr 22, 2009, at 2:53 AM, Simon Josefsson wrote:

>
> Nicolas Williams <[e-mail]> writes:
>
>> http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
>
> Thanks.  Something along these lines is needed before we can implement
> SCRAM and GS2.

Why?

In particular, do you think it not possible (or not feasible) to  
implement SCRAM and/or GS2 without change to RFC 4422 and, if so, why?

My take on SCRAM, at least, is that it's quite implementable without  
change to RFC 4422.

>
>
>> Changes from -02:
>>
>> - added channel binding type negotiation through pseudo-mechanism  
>> names
>>    - CB-tls-srv-endpoint
>>    - CB-tls-unique
>>    - If the server doesn't list any then the client assumes all  
>> channel
>>      binding types available on the client side are also available on
>>      the server side.  But the server SHOULD list them.
>
> I'm concerned that (today) the implementation of a SASL mechanism does
> not have easy access to the list of supported SASL mechanism exposed  
> by
> the server.

Given that mechanism negotiation is "protocol specific", this should  
not be surprising to anyone.  In fact, protocols need not even provide  
a mechanism negotiation facility.

> Thus, I'm not convinced the pseudo mechanism approach will
> be easy to implement.

Given that today some server implementations find it hard to limit the  
advertisement of EXTERNAL to instances where the server has associated  
an identity for the client at some lower-level, we can surmise that  
some implementations will find this pseudo mechanism approach hard to  
implement.

> Could we explore encoding both the channel binding negotiation and
> channel binding type negotiation in the SASL mechanism name?

I just wish we'd "explore" some where other than the in the base  
specification.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3NIl9OD095343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 11:47:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3NIl98f095342; Thu, 23 Apr 2009 11:47:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3NIkvYg095326 for <[e-mail]>; Thu, 23 Apr 2009 11:47:08 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Thu, 23 Apr 2009 19:46:56 +0100
X-SMTP-Protocol-Errors: NORDNS Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: draft-josefsson-sasl-external-channel-03
Date: Thu, 23 Apr 2009 11:46:51 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 22, 2009, at 3:24 AM, Simon Josefsson wrote:

> Maybe Kurt could describe his use case?

Well, basically, it comes down to limitation that RFC 4422 states  
EXTERNAL has:

    In absence of some a
    priori agreement between the client and the server, the client  
cannot
    make any assumption as to what external means the server has used to
    obtain the client's credentials, nor make an assumption as to the
    form of credentials.

So, for instance, if a client established an identity using TLS (over  
TCP/IP), the client cannot assume the server pulls from TLS.  It just  
as well be pulling an identity from IP (the client's IP address).  As  
you noted in a subsequent post, an implementation might pull up the IP  
address to associate a "localhost" identity with the client.  This  
same issue happens when the client does TLS over IPC.  The client  
cannot know if the identity pulled up is from TLS or IPC layer.

Now, in many cases, the client may not care from where the server  
pulls.  It seems more likely if the client would care about what  
identity was associated to it by the server instead of the where.  For  
this, application protocols can offer "who am i?" operations.   Note  
that "who am i?" was actually introduced to solve a bit different  
issue... the issue that client cannot make assumptions about the  
identity a client associated with the credentials (even when those  
credentials include an user identifier).

I think EXTERNAL is generally "good enough", especially when combined  
with "who am i?" operations.

The use case I was thinking of was "Client wants to server to pull up  
from a particular layer (usually the layer immediately below the  
application layer protocol (e.g., TLS))".

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3NE5UCa072730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 07:05:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3NE5UHo072729; Thu, 23 Apr 2009 07:05:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3NE5Gi3072716 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 23 Apr 2009 07:05:27 -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 n3NE5GNJ004884 for <[e-mail]>; Thu, 23 Apr 2009 14:05:16 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 n3NE5FLo042267 for <[e-mail]>; Thu, 23 Apr 2009 08:05:16 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3NDmFLm016873; Thu, 23 Apr 2009 08:48:15 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3NDmCEV016872; Thu, 23 Apr 2009 08:48:12 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 23 Apr 2009 08:48:12 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 22, 2009 at 06:03:15PM -0400, Jeffrey Hutzelman wrote:
> If there is an a priori agreement as to what EXTERNAL is for, then there is 
> no confusion.
> 
> Lacking such agreement, the only way you can know what EXTERNAL means is if 
> it always means the same thing.  If that were the case (for example, if it 

Or if it could only reasonably mean one thing.

> always meant "use TLS") and it were simply undocumented, then it would be 
> appropriate to amend the definition of EXTERNLA to say what it means.  But 
> in fact, it appears that it does _not_ always mean the same thing.

I can't see when the client and server could be confused _today_ by what
EXTERNAL means.

> We could say "it means use the highest-layer e2e channel", but that would 
> be a backward-incompatible change, since it doesn't always mean that now.

Only if that actually changes EXTERNAL in any presently feasible
scenarios.

> We could say "it means use TLS, except when it doesn't", which would be 
> very close to the deployed reality today.  Unfortunately, the "except when 
> it doesn't" has the effect that this statement is not semantically 
> different from what the current spec says -- you still have to know whether 
> it means TLS, and if not, what else it means instead.
> 
> So, I think amending EXTERNAL is a lost cause, and we should just punt and 
> concentrate on EXTERNAL-*.

I'm not arguing otherwise.  I'm arguing that we can also clarify
EXTERNAL.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N88WxS044625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 01:08:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3N88Wf8044622; Thu, 23 Apr 2009 01:08: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-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N88UcZ044616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 23 Apr 2009 01:08:31 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lwtyv-0007gi-K1; Thu, 23 Apr 2009 10:08:30 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090423:[e-mail]::GyEUwvAp30Hp+ore:2ih4
X-Hashcash: 1:22:090423:[e-mail]::9dnoQM3sOMkmH4tP:UPat
Date: Thu, 23 Apr 2009 10:08:28 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 22 Apr 2009 16:19:54 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Wed, Apr 22, 2009 at 11:07:52PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> >> > That's what it says, but does anyone ever do that, or does everyone take
>> >> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
>> >> > the latter.
>> >> 
>> >> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
>> >> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
>> >> recall correctly) use EXTERNAL for localhost based authentication.  Some
>> >> applications probably use EXTERNAL for client-TLS too.
>> >
>> > But my earlier point stands: it's never the case, today, that there's
>> > any confusion as to what EXTERNAL means.  A rule can be stated to
>> > clarify what EXTERNAL means in future cases where there would be
>> > confusion.
>> 
>> Today the client can never know what mechanism the server used.  The
>> server can never know what mechanism the client intended to be used.  So
>> I think we disagree that there is confusion what EXTERNAL means today.
>> Reducing that perceived confusion is the point of the draft.
>
> If it can only have meant one thing then there can be no confusion.
>
> Confusion enters the picture when there can have been multiple answers.

Right, and I believe there is sufficient potential for multiple answers
to warrant work on EXTERNAL-*.

> Also, why should the client care which ID was used as long as the client
> requested a specific authzid?  :)

In some cases the client does not specify an authzid.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N84hJb044397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 01:04:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3N84hw5044396; Thu, 23 Apr 2009 01:04:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N84esX044387 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 23 Apr 2009 01:04:42 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LwtvC-0007gX-C6; Thu, 23 Apr 2009 10:04:38 +0200
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090423:[e-mail]::AOaAdnHrmA2+O0x5:1J/q
X-Hashcash: 1:22:090423:[e-mail]::qSke7Z+wma4tHx7N:7qQo
X-Hashcash: 1:22:090423:[e-mail]::Tl0WvLtO4ZKJp+t6:KIvD
Date: Thu, 23 Apr 2009 10:04:37 +0200
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Wed, 22 Apr 2009 18:03:15 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> So, I think amending EXTERNAL is a lost cause, and we should just punt
> and concentrate on EXTERNAL-*.

Agreed.  Perhaps the background hasn't been clear: I considered to
publish an update of EXTERNAL with clarified semantics, i.e., "use
client credentials from the highest layered TLS channel".  However, I
think this WG has seen enough attempts to retrofit slightly modified
semantics on CRAM-MD5 and DIGEST-MD5 already (although we succeeded with
PLAIN).  My primary use case is to get client-TLS credentials reused in
SASL, so an update to EXTERNAL would have worked for me.  If someone
wants to drive that effort, I would be happy if it succeeded.  I believe
that is unlikely to succeed, because EXTERNAL appears to be deployed
with incompatible semantics already.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N7u0wE043846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2009 00:56:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3N7u0tB043845; Thu, 23 Apr 2009 00:56:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N7tliO043828 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 23 Apr 2009 00:55:59 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lwtmb-0007gJ-Cr; Thu, 23 Apr 2009 09:55:46 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090423:[e-mail]::4PLQL4gfvXZXehge:0xoy
X-Hashcash: 1:22:090423:[e-mail]::/iPbE8FDJoQbHfzy:ZfXK
Date: Thu, 23 Apr 2009 09:55:44 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Wed, 22 Apr 2009 19:45:48 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Apr 22, 2009, at 1:29 PM, Simon Josefsson wrote:
>
>>
>> I noticed a minor nit in RFC 4422 when writing IANA section for
>> EXTERNAL-*, namely that in section 7.1.1 I think ' (or prefix for the
>> family)' is not relevant.  Should it be removed?
>
> Yes.

Great.

> I also noticed that doesn't say anything about registration of members
> of a family.
> To address this, I propose adding the following to the end of 7.1.2.
>
> It is expected that the owner of the family provide appropriate
> guidance to IANA regarding registration of family members.  In absence
> of any particular guidance, permission of the family owner is required
> to register a member of the family.
>
> All IESG-owned families, unless otherwise specified in an IETF
> document detailing the family of mechanism, require Expert Review
> (as discussed above).

That is useful to add.  The text works for me.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N2k6R9027480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 19:46:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3N2k5GT027479; Wed, 22 Apr 2009 19:46:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3N2jr0Q027462 for <[e-mail]>; Wed, 22 Apr 2009 19:46:04 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <Se=WXwB=[e-mail]>; Thu, 23 Apr 2009 03:45:52 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt
Date: Wed, 22 Apr 2009 19:45:48 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 22, 2009, at 1:29 PM, Simon Josefsson wrote:

>
> I noticed a minor nit in RFC 4422 when writing IANA section for
> EXTERNAL-*, namely that in section 7.1.1 I think ' (or prefix for the
> family)' is not relevant.  Should it be removed?

Yes.

I also noticed that doesn't say anything about registration of members  
of a family.
To address this, I propose adding the following to the end of 7.1.2.

It is expected that the owner of the family provide appropriate
guidance to IANA regarding registration of family members.  In absence
of any particular guidance, permission of the family owner is required
to register a member of the family.

All IESG-owned families, unless otherwise specified in an IETF
document detailing the family of mechanism, require Expert Review
(as discussed above).




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MM3UXD010754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 15:03:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MM3UQ4010753; Wed, 22 Apr 2009 15:03:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MM3Imb010736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 22 Apr 2009 15:03:30 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3MM3FDV003487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 18:03:16 -0400 (EDT)
Date: Wed, 22 Apr 2009 18:03:15 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
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]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, April 22, 2009 04:19:54 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

>
> On Wed, Apr 22, 2009 at 11:07:52PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>>
>> >> > That's what it says, but does anyone ever do that, or does everyone
>> >> > take EXTERNAL to mean "use the user authenticated by TLS"?  I
>> >> > suspect it's the latter.
>> >>
>> >> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
>> >> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils,
>> >> if I recall correctly) use EXTERNAL for localhost based
>> >> authentication.  Some applications probably use EXTERNAL for
>> >> client-TLS too.
>> >
>> > But my earlier point stands: it's never the case, today, that there's
>> > any confusion as to what EXTERNAL means.  A rule can be stated to
>> > clarify what EXTERNAL means in future cases where there would be
>> > confusion.
>>
>> Today the client can never know what mechanism the server used.  The
>> server can never know what mechanism the client intended to be used.  So
>> I think we disagree that there is confusion what EXTERNAL means today.
>> Reducing that perceived confusion is the point of the draft.
>
> If it can only have meant one thing then there can be no confusion.
>
> Confusion enters the picture when there can have been multiple answers.
>
> Also, why should the client care which ID was used as long as the client
> requested a specific authzid?  :)

If there is an a priori agreement as to what EXTERNAL is for, then there is 
no confusion.

Lacking such agreement, the only way you can know what EXTERNAL means is if 
it always means the same thing.  If that were the case (for example, if it 
always meant "use TLS") and it were simply undocumented, then it would be 
appropriate to amend the definition of EXTERNLA to say what it means.  But 
in fact, it appears that it does _not_ always mean the same thing.

We could say "it means use the highest-layer e2e channel", but that would 
be a backward-incompatible change, since it doesn't always mean that now.

We could say "it means use TLS, except when it doesn't", which would be 
very close to the deployed reality today.  Unfortunately, the "except when 
it doesn't" has the effect that this statement is not semantically 
different from what the current spec says -- you still have to know whether 
it means TLS, and if not, what else it means instead.

So, I think amending EXTERNAL is a lost cause, and we should just punt and 
concentrate on EXTERNAL-*.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MLTZB3008500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 14:29:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MLTZG5008499; Wed, 22 Apr 2009 14:29:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MLTOxM008469 for <[e-mail]>; Wed, 22 Apr 2009 14:29:34 -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 n3MLTN7M016037 for <[e-mail]>; Wed, 22 Apr 2009 21:29:24 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3MLTN8O019994 for <[e-mail]>; Wed, 22 Apr 2009 15:29:23 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MLJsfP016529; Wed, 22 Apr 2009 16:19:54 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MLJs6P016528; Wed, 22 Apr 2009 16:19:54 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 22 Apr 2009 16:19:54 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 22, 2009 at 11:07:52PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> >> > That's what it says, but does anyone ever do that, or does everyone take
> >> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
> >> > the latter.
> >> 
> >> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
> >> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
> >> recall correctly) use EXTERNAL for localhost based authentication.  Some
> >> applications probably use EXTERNAL for client-TLS too.
> >
> > But my earlier point stands: it's never the case, today, that there's
> > any confusion as to what EXTERNAL means.  A rule can be stated to
> > clarify what EXTERNAL means in future cases where there would be
> > confusion.
> 
> Today the client can never know what mechanism the server used.  The
> server can never know what mechanism the client intended to be used.  So
> I think we disagree that there is confusion what EXTERNAL means today.
> Reducing that perceived confusion is the point of the draft.

If it can only have meant one thing then there can be no confusion.

Confusion enters the picture when there can have been multiple answers.

Also, why should the client care which ID was used as long as the client
requested a specific authzid?  :)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ML7xPl007135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 14:07:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3ML7xDb007134; Wed, 22 Apr 2009 14:07:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ML7uFU007127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Apr 2009 14:07:58 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lwjfe-00076D-80; Wed, 22 Apr 2009 23:07:54 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090422:[e-mail]::/QUYJT7SEDzKrcjY:1opC
X-Hashcash: 1:22:090422:[e-mail]::R42gEkxYPZKMqTwU:99V3
Date: Wed, 22 Apr 2009 23:07:52 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 22 Apr 2009 15:41:51 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

>> > That's what it says, but does anyone ever do that, or does everyone take
>> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
>> > the latter.
>> 
>> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
>> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
>> recall correctly) use EXTERNAL for localhost based authentication.  Some
>> applications probably use EXTERNAL for client-TLS too.
>
> But my earlier point stands: it's never the case, today, that there's
> any confusion as to what EXTERNAL means.  A rule can be stated to
> clarify what EXTERNAL means in future cases where there would be
> confusion.

Today the client can never know what mechanism the server used.  The
server can never know what mechanism the client intended to be used.  So
I think we disagree that there is confusion what EXTERNAL means today.
Reducing that perceived confusion is the point of the draft.

>> >> >  - The string "a002" in the example given should probably be explained,
>> >> >    or even removed (it seems superfluous, besides, 
>> >> 
>> >> It can't be removed, or the example wouldn't be valid ACAP, if I
>> >> understand correctly.  The same is in RFC 4422.  I don't think we need
>> >> to explain the ACAP protocol.  But maybe I'm missing something...
>> >
>> > Ah, ACAP.  But you don't need a specific application for the example.
>> 
>> We could add other examples too, but I don't see a point in removing the
>> current examples.  They are only examples, after all.  That text is
>> copied directly from RFC 4422, so I think it is useful to preserve for
>> historic comparisons too.
>
> Was there a reference to ACAP?  If not, add an informational one :)

There is one already.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MKq13q087788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 13:52:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MKq1Zg087787; Wed, 22 Apr 2009 13:52:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MKpcYN087376 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 22 Apr 2009 13:51:48 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3MKpPi7023646 for <[e-mail]>; Wed, 22 Apr 2009 20:51:37 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3MKpO0Z054391 for <[e-mail]>; Wed, 22 Apr 2009 14:51:24 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MKfssc016393; Wed, 22 Apr 2009 15:41:54 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MKfpfO016392; Wed, 22 Apr 2009 15:41:51 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 22 Apr 2009 15:41:51 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 22, 2009 at 10:26:41PM +0200, Simon Josefsson wrote:
> 
> Nicolas Williams <[e-mail]> writes:
> 
> > On Wed, Apr 22, 2009 at 12:24:00PM +0200, Simon Josefsson wrote:
> >> Nicolas Williams <[e-mail]> writes:
> >> 
> >> > On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
> >> >> Complete diff:
> >> >> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
> >> >> 
> >> >> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
> >> >
> >> > A few comments:
> >> >
> >> >  - I doubt today there's ever any cases where there could confusion as
> >> >    to what channel "EXTERNAL" refers to.  The confusion and the need for
> >> >    a priori agreement is theoretical -- if so then the text should
> >> >    probably reflect that, otherwise examples should be given.
> >> 
> >> I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
> >> refers to needs to be arranged out of band.  The point of this document
> >> [...]
> >
> > That's what it says, but does anyone ever do that, or does everyone take
> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
> > the latter.
> 
> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
> recall correctly) use EXTERNAL for localhost based authentication.  Some
> applications probably use EXTERNAL for client-TLS too.

But my earlier point stands: it's never the case, today, that there's
any confusion as to what EXTERNAL means.  A rule can be stated to
clarify what EXTERNAL means in future cases where there would be
confusion.

> >> >  - The string "a002" in the example given should probably be explained,
> >> >    or even removed (it seems superfluous, besides, 
> >> 
> >> It can't be removed, or the example wouldn't be valid ACAP, if I
> >> understand correctly.  The same is in RFC 4422.  I don't think we need
> >> to explain the ACAP protocol.  But maybe I'm missing something...
> >
> > Ah, ACAP.  But you don't need a specific application for the example.
> 
> We could add other examples too, but I don't see a point in removing the
> current examples.  They are only examples, after all.  That text is
> copied directly from RFC 4422, so I think it is useful to preserve for
> historic comparisons too.

Was there a reference to ACAP?  If not, add an informational one :)

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MKTfCk084757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 13:29:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MKTfgw084756; Wed, 22 Apr 2009 13:29:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MKTS9n084733 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Apr 2009 13:29:40 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lwj4Q-00075F-Rj for [e-mail]; Wed, 22 Apr 2009 22:29:27 +0200
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090422:[e-mail]::3Af/QCUlnyDz14qu:5uR7
X-Hashcash: 1:22:090422:[e-mail]::Mm6j7g4GPV4di+vl:uy6C
Date: Wed, 22 Apr 2009 22:29:25 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Wed, 15 Apr 2009 15:36:13 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I noticed a minor nit in RFC 4422 when writing IANA section for
EXTERNAL-*, namely that in section 7.1.1 I think ' (or prefix for the
family)' is not relevant.  Should it be removed?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MKR6or084540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 13:27:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MKR6q8084539; Wed, 22 Apr 2009 13:27:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MKQqv3084517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Apr 2009 13:27:05 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lwj1v-0002LG-1Q for [e-mail]; Wed, 22 Apr 2009 20:26:51 +0000
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 22 Apr 2009 20:26:51 +0000
Received: from simon by c80-216-29-127.bredband.comhem.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 22 Apr 2009 20:26:51 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  Simon Josefsson <[e-mail]>
Subject:  Re: draft-josefsson-sasl-external-channel-03
Date:  Wed, 22 Apr 2009 22:26:41 +0200
Lines: 46
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c80-216-29-127.bredband.comhem.se
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090422:gmane.ietf.sasl::dZdgCwVIk4bwNh0A:0mKPU
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.92 (gnu/linux)
Cancel-Lock: sha1:nMJdDHPPEd7SqyEBTNXNOES7Sjk=
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Wed, Apr 22, 2009 at 12:24:00PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
>> >> Complete diff:
>> >> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
>> >> 
>> >> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
>> >
>> > A few comments:
>> >
>> >  - I doubt today there's ever any cases where there could confusion as
>> >    to what channel "EXTERNAL" refers to.  The confusion and the need for
>> >    a priori agreement is theoretical -- if so then the text should
>> >    probably reflect that, otherwise examples should be given.
>> 
>> I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
>> refers to needs to be arranged out of band.  The point of this document
>> [...]
>
> That's what it says, but does anyone ever do that, or does everyone take
> EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
> the latter.

Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
recall correctly) use EXTERNAL for localhost based authentication.  Some
applications probably use EXTERNAL for client-TLS too.

>> >  - The string "a002" in the example given should probably be explained,
>> >    or even removed (it seems superfluous, besides, 
>> 
>> It can't be removed, or the example wouldn't be valid ACAP, if I
>> understand correctly.  The same is in RFC 4422.  I don't think we need
>> to explain the ACAP protocol.  But maybe I'm missing something...
>
> Ah, ACAP.  But you don't need a specific application for the example.

We could add other examples too, but I don't see a point in removing the
current examples.  They are only examples, after all.  That text is
copied directly from RFC 4422, so I think it is useful to preserve for
historic comparisons too.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MGIc5a064056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 09:18:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MGIbdm064055; Wed, 22 Apr 2009 09:18:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MGIRg6064035 for <[e-mail]>; Wed, 22 Apr 2009 09:18:37 -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 n3MGIQDI025718 for <[e-mail]>; Wed, 22 Apr 2009 16:18:26 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 n3MGIQeR030405 for <[e-mail]>; Wed, 22 Apr 2009 10:18:26 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MG8uWs016142; Wed, 22 Apr 2009 11:08:56 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MG8ulF016141; Wed, 22 Apr 2009 11:08:56 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 22 Apr 2009 11:08:56 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 22, 2009 at 12:24:00PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
> >> Complete diff:
> >> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
> >> 
> >> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
> >
> > A few comments:
> >
> >  - I doubt today there's ever any cases where there could confusion as
> >    to what channel "EXTERNAL" refers to.  The confusion and the need for
> >    a priori agreement is theoretical -- if so then the text should
> >    probably reflect that, otherwise examples should be given.
> 
> I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
> refers to needs to be arranged out of band.  The point of this document
> [...]

That's what it says, but does anyone ever do that, or does everyone take
EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
the latter.

> >  - When "EXTERNAL" is used one would think that the highest-layer,
> >    innermost end-to-end channel is the one it ought to refer to.  It
> >    strikes me as a good idea to state that.
> 
> This is mentioned in section 3 for EXTERNAL-TLS.  I believe this belongs
> in each EXTERNAL-FOO mechanism rather than in the generic framework, but
> I agree that this needs to be stated.  I have added this section:
> 
>   <t>The external security channel to use is implied by the SASL
>     mechanism name.  The channel has to be uniquely identifiable at
>     both cliend and server side.  This means that mechanisms
>     registered in this family MUST detail which channel should be
>     chosen if there are layered channels of the same type.</t>

OK.

> >  - An informative reference to TLS (RFC5246) seems necessary.  (Or
> >  maybe even normative.)
> 
> I've made it normative.  (There was an informative reference.)

OK.

> >  - The string "a002" in the example given should probably be explained,
> >    or even removed (it seems superfluous, besides, 
> 
> It can't be removed, or the example wouldn't be valid ACAP, if I
> understand correctly.  The same is in RFC 4422.  I don't think we need
> to explain the ACAP protocol.  But maybe I'm missing something...

Ah, ACAP.  But you don't need a specific application for the example.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MFTC2S059118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 08:29:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MFTCc1059117; Wed, 22 Apr 2009 08:29:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MFT1qA059105 for <[e-mail]>; Wed, 22 Apr 2009 08:29:11 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3MFT0lC026364 for <[e-mail]>; Wed, 22 Apr 2009 15:29:00 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 n3MFT0C4056237 for <[e-mail]>; Wed, 22 Apr 2009 09:29:00 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MFJSxH016080; Wed, 22 Apr 2009 10:19:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MFJREU016079; Wed, 22 Apr 2009 10:19:27 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 22 Apr 2009 10:19:27 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 22, 2009 at 11:53:35AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
> 
> Thanks.  Something along these lines is needed before we can implement
> SCRAM and GS2.

Well, no, but we do need this before SCRAM and GS2 can progress, IMO.

> > Changes from -02:
> >
> >  - added channel binding type negotiation through pseudo-mechanism names
> >     - CB-tls-srv-endpoint
> >     - CB-tls-unique
> >     - If the server doesn't list any then the client assumes all channel
> >       binding types available on the client side are also available on
> >       the server side.  But the server SHOULD list them.
> 
> I'm concerned that (today) the implementation of a SASL mechanism does
> not have easy access to the list of supported SASL mechanism exposed by
> the server.  Thus, I'm not convinced the pseudo mechanism approach will
> be easy to implement.

Making that list available to *some* component that can make the choice
is part of the scheme.  The current text allows that to be the
application, the framework and/or the mechanism:

 - The application on the client side can make the choice of channel
   binding type by:
   
   a) for each locally available mechanism inquire whether it requires
   unique channel bindings and, if the server didn't advertise support
   for those or the client doesn't have support for those, then
   eliminate that mechanism from the list,

   b) pick a mechanism from the list resulting from (a),

   c) if the chosen mechanism requires unique channel bindings, then
   choose unique channel bindings as the channel binding type, else
   choose end-point channel bindings if available.

 - The framework can make the choice in exactly the same way as the
   application, *provided* that the application gives the framework the
   server's advertised mechanism list.

 - The mechanism can make the choice *provided* that the application
   gives it the server's advertised mechanism list.

> Could we explore encoding both the channel binding negotiation and
> channel binding type negotiation in the SASL mechanism name?
> 
> For SCRAM, you would then have these mechanisms:
> 
>    SCRAM
>    SCRAM-TLSUNIQUE
>    SCRAM-TLSENDPOINT

N * M -> bad.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MFC3tf057496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 08:12:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MFC301057495; Wed, 22 Apr 2009 08:12:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from thing.verysmall.org (thing.verysmall.org [89.234.8.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MFBpR7057473 for <[e-mail]>; Wed, 22 Apr 2009 08:12:01 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.40.155] (port-87-193-147-74.static.qsc.de [87.193.147.74]) by thing.verysmall.org (Postfix) with ESMTPA id C8B391706F; Wed, 22 Apr 2009 15:32:36 +0000 (UTC)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Iv Ray <[e-mail]>
To: Dan White <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: slow authentication
Date: Wed, 22 Apr 2009 17:11:49 +0200
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 22.04.2009, at 16:40, Dan White wrote:
> Iv,
>
> The Cyrus SASL mailing list might be more appropriate for this  
> question:
>
> http://cyrusimap.web.cmu.edu/lists.html#lists
>
> Some areas to look at - If you're using SSL/TLS during  
> authentication, verify whether you're using /dev/random or /dev/ 
> urandom (see the manpage for 'random'). Using /dev/random may slow  
> down your initial connection if you don't have enough entropy.
>
> I would look more at sasl_pwcheck_method than sasl_mech_list. If  
> sasl_pwcheck_method is not specified, it will attempt all installed  
> pwcheck_methods in order. Try specifying your preferred method  
> explicitly, if it isn't already.
>
> If using the saslauthd pwcheck_method, trouble shoot saslauthd first  
> for delays (testsaslauthd).
>
> If using an exotic auxprop store method (e.g. MySQL, LDAP), trouble  
> shoot those separately. Turn off sasl_auto_transition, if enabled,  
> for trouble shooting.
>
> Set your sasl_log_level to 7. Monitor your syslog/auth.log.
>
> - Dan

Dan,

Thanks a lot! - I am starting to follow your notes.

And sorry again for confusing the list, I'll keep that in mind.

Thank you again,
Iv



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MEeod3055261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 07:40:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MEeo8L055260; Wed, 22 Apr 2009 07:40:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pinky.olp.net (pinky.olp.net [65.161.252.89]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MEedjF055230 for <[e-mail]>; Wed, 22 Apr 2009 07:40:49 -0700 (MST) (envelope-from [e-mail])
Received: from btc_dell_server.bixbytelephone.com (btc.olp.net [65.161.252.42]) by pinky.olp.net (Postfix) with ESMTP id 2A329292CEA for <[e-mail]>; Wed, 22 Apr 2009 09:41:11 -0500 (CDT)
Received: from [10.0.17.82] ([10.0.17.82]) by btc_dell_server.bixbytelephone.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 09:40:38 -0500
Message-ID: <[e-mail]>
Date: Wed, 22 Apr 2009 09:40:38 -0500
From: Dan White <[e-mail]>
User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Iv Ray <[e-mail]>
CC: [e-mail]
Subject: Re: slow authentication
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Apr 2009 14:40:38.0632 (UTC) FILETIME=[4DC8E680:01C9C358]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Iv Ray wrote:
>
> Hello everyone,
>
> I am running a mail server compiled from the latest versions of 
> Postfix and Cyrus IMAP with Cyrus SASL authentication on FreeBSD 6.x.
>
> Some months ago the web mail (Squirrelmail) became extremely slow to 
> login and on previous/next page inside the mail folder - it takes 
> about 25 seconds both to login and to change page.
>
> E-mail clients like Mac Mail became slow in the beginning only.
>
> I did some research and had some conversations on the Cyrus IMAP 
> mailing list and the direction so far is that the slowness is in the 
> authentication process (e-mail clients like Mac Mail experience 
> slowness only in the beginning, because they seem to authenticate only 
> then, while Squirrelmail authenticates on every request). I was 
> advised to turn off all Cyrus SASL modules except PLAIN and I did so, 
> however the 25 seconds delay persists.
>
> Does this sound familiar to someone?
>
> Any help would be appreciated.
>
> Iv
>

Iv,

The Cyrus SASL mailing list might be more appropriate for this question:

http://cyrusimap.web.cmu.edu/lists.html#lists

Some areas to look at - If you're using SSL/TLS during authentication, 
verify whether you're using /dev/random or /dev/urandom (see the manpage 
for 'random'). Using /dev/random may slow down your initial connection 
if you don't have enough entropy.

I would look more at sasl_pwcheck_method than sasl_mech_list. If 
sasl_pwcheck_method is not specified, it will attempt all installed 
pwcheck_methods in order. Try specifying your preferred method 
explicitly, if it isn't already.

If using the saslauthd pwcheck_method, trouble shoot saslauthd first for 
delays (testsaslauthd).

If using an exotic auxprop store method (e.g. MySQL, LDAP), trouble 
shoot those separately. Turn off sasl_auto_transition, if enabled, for 
trouble shooting.

Set your sasl_log_level to 7. Monitor your syslog/auth.log.

- Dan



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MAO9Tm032065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 03:24:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3MAO9Ji032064; Wed, 22 Apr 2009 03:24:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3MAO5Pk032053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Apr 2009 03:24:08 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LwZcY-0005YU-3U; Wed, 22 Apr 2009 12:24:03 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090422:[e-mail]::s911R/xYdh76Jz6H:2GMU
X-Hashcash: 1:22:090422:[e-mail]::8J5QA7/HA75L7aQ+:BYKg
Date: Wed, 22 Apr 2009 12:24:00 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 21 Apr 2009 15:17:06 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
>> Complete diff:
>> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
>> 
>> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
>
> A few comments:
>
>  - I doubt today there's ever any cases where there could confusion as
>    to what channel "EXTERNAL" refers to.  The confusion and the need for
>    a priori agreement is theoretical -- if so then the text should
>    probably reflect that, otherwise examples should be given.

I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
refers to needs to be arranged out of band.  The point of this document
is to move the negotiation in band.  Since RFC 4422 rules the
negotiation out of scope, there is by definition always confusion which
channel is intended, and even on successful authentication there is in
practice no in-band guarantees that both sides intended the same
channel.

Maybe Kurt could describe his use case?

>  - When "EXTERNAL" is used one would think that the highest-layer,
>    innermost end-to-end channel is the one it ought to refer to.  It
>    strikes me as a good idea to state that.

This is mentioned in section 3 for EXTERNAL-TLS.  I believe this belongs
in each EXTERNAL-FOO mechanism rather than in the generic framework, but
I agree that this needs to be stated.  I have added this section:

  <t>The external security channel to use is implied by the SASL
    mechanism name.  The channel has to be uniquely identifiable at
    both cliend and server side.  This means that mechanisms
    registered in this family MUST detail which channel should be
    chosen if there are layered channels of the same type.</t>

>  - An informative reference to TLS (RFC5246) seems necessary.  (Or
>  maybe even normative.)

I've made it normative.  (There was an informative reference.)

>  - The string "a002" in the example given should probably be explained,
>    or even removed (it seems superfluous, besides, 

It can't be removed, or the example wouldn't be valid ACAP, if I
understand correctly.  The same is in RFC 4422.  I don't think we need
to explain the ACAP protocol.  But maybe I'm missing something...

>  application protocol bindings of SASL are not needed in order to have
>  an example, no?).

...because I don't understand what you mean here, explain?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3M9s0lS028346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 02:54:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3M9s01P028345; Wed, 22 Apr 2009 02:54:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3M9rjNj028294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 22 Apr 2009 02:53:58 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LwZ98-0005Xb-KU; Wed, 22 Apr 2009 11:53:40 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090422:[e-mail]::CaFQ3USuS5cCWDZ3:7YNn
X-Hashcash: 1:22:090422:[e-mail]::/dexy7aH9/VLCFYk:7sAs
X-Hashcash: 1:22:090422:[e-mail]::28I3LKv0PeVbCXmk:OuMy
X-Hashcash: 1:22:090422:[e-mail]::Hp0+f5aSfsWxTRkA:U5Yz
Date: Wed, 22 Apr 2009 11:53:35 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 21 Apr 2009 14:50:37 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt

Thanks.  Something along these lines is needed before we can implement
SCRAM and GS2.

> Changes from -02:
>
>  - added channel binding type negotiation through pseudo-mechanism names
>     - CB-tls-srv-endpoint
>     - CB-tls-unique
>     - If the server doesn't list any then the client assumes all channel
>       binding types available on the client side are also available on
>       the server side.  But the server SHOULD list them.

I'm concerned that (today) the implementation of a SASL mechanism does
not have easy access to the list of supported SASL mechanism exposed by
the server.  Thus, I'm not convinced the pseudo mechanism approach will
be easy to implement.

Could we explore encoding both the channel binding negotiation and
channel binding type negotiation in the SASL mechanism name?

For SCRAM, you would then have these mechanisms:

   SCRAM
   SCRAM-TLSUNIQUE
   SCRAM-TLSENDPOINT

The two latter mechanisms imply channel binding support, using the
explicit channel binding types.

For Kerberos V5 under GS2 we'd have:

   GS2-KRB5
   GS2-KRB5-TLSUNIQUE
   GS2-KRB5-TLSENDPOINT

This approach would resolve my old concern with channel binding type
negotiation in RFC 5056 in this context.  It is taken care of at the
SASL mechanism layer.

(Btw, SASL mechanisms are upper case, thus 'CB-tls-srv-endpoint'
wouldn't work.)

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3M7ljJX017866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 00:47:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3M7lj3n017864; Wed, 22 Apr 2009 00:47:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from thing.verysmall.org (thing.verysmall.org [89.234.8.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3M7lhvv017857 for <[e-mail]>; Wed, 22 Apr 2009 00:47:44 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.42.149] (port-87-193-147-74.static.qsc.de [87.193.147.74]) by thing.verysmall.org (Postfix) with ESMTPA id 0B1E817058 for <[e-mail]>; Wed, 22 Apr 2009 08:08:30 +0000 (UTC)
Message-Id: <[e-mail]>
From: Iv Ray <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: slow authentication
Date: Wed, 22 Apr 2009 09:47:41 +0200
X-Mailer: Apple Mail (2.930.3)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello everyone,

I am running a mail server compiled from the latest versions of  
Postfix and Cyrus IMAP with Cyrus SASL authentication on FreeBSD 6.x.

Some months ago the web mail (Squirrelmail) became extremely slow to  
login and on previous/next page inside the mail folder - it takes  
about 25 seconds both to login and to change page.

E-mail clients like Mac Mail became slow in the beginning only.

I did some research and had some conversations on the Cyrus IMAP  
mailing list and the direction so far is that the slowness is in the  
authentication process (e-mail clients like Mac Mail experience  
slowness only in the beginning, because they seem to authenticate only  
then, while Squirrelmail authenticates on every request). I was  
advised to turn off all Cyrus SASL modules except PLAIN and I did so,  
however the 25 seconds delay persists.

Does this sound familiar to someone?

Any help would be appreciated.

Iv



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LKlMLo083997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 13:47:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3LKlMSO083996; Tue, 21 Apr 2009 13:47:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LKlLku083989 for <[e-mail]>; Tue, 21 Apr 2009 13:47:21 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LKlLcN026567 for <[e-mail]>; Tue, 21 Apr 2009 20:47:21 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 n3LKlLOH044725 for <[e-mail]>; Tue, 21 Apr 2009 14:47:21 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LKbqkS015593; Tue, 21 Apr 2009 15:37:52 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LKbpGp015592; Tue, 21 Apr 2009 15:37:51 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 21 Apr 2009 15:37:51 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Cc: Kurt Zeilenga <[e-mail]>
Subject: Comments on YAP
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I looked at draft-zeilenga-sasl-yap-03 when revising
draft-ietf-sasl-channel-bindings.

Here are some comments:

 - YAP as a variant of SCRAM seems like a good idea: you can reuse the
   SCRAM PBKDF and key management.  That means less administration, and
   also that you could normatively refer to SCRAM for parts of YAP, thus
   making the YAP I-D smaller.

 - IMO there should be a server->client message for mutual
   authentication (though as with SCRAM there's no server name).  The
   following is a YAP-as-variant-of-SCRAM exchange as I imagine it:

    C: p,a=nico,n=Nico,p=<ClientKey XOR
			    HMAC(StoredKey, "n=Nico,cb=p,a=nico,tls-unique:...")
    S: v=HMAC(ServerKey, <client's first message>)
    C: <empty>  (optional depending on the app protocol)
    S: <outcome of authentication>

   With this you'd save a round-trip compared to SCRAM and could qualify
   for the Standards-Track (I guess what makes YAP Experimental is the
   lack of mutual authentication).

 - When the client has not cached the salt and/or PBKDF iteration counts
   or the cached values are out of date the mechanism could devolve into
   SCRAM:

    C: n,a=nico,n=Nico,p=<ClientKey XOR
			    HMAC(StoredKey, "n=Nico,cb=n,a=nico,tls-unique:...")
    S: s=<salt>,i=<iteration-count>
    C: n,a=nico,n=Nico,p=<ClientKey XOR ...>
    S: v=HMAC(ServerKey, <client's second message>)
    C: <empty>  (optional depending on the app protocol)
    S: <outcome of authentication>

 - You could even have YAP be exactly like SCRAM when the given channel
   binding type is not a unique channel binding type.



Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LKQnj6082412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 13:26:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3LKQnTr082410; Tue, 21 Apr 2009 13:26:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LKQbY7082353 for <[e-mail]>; Tue, 21 Apr 2009 13:26:48 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LKQb8b017255 for <[e-mail]>; Tue, 21 Apr 2009 20:26:37 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LKQbLn029893 for <[e-mail]>; Tue, 21 Apr 2009 14:26:37 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LKH6So015582; Tue, 21 Apr 2009 15:17:06 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LKH6WT015581; Tue, 21 Apr 2009 15:17:06 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 21 Apr 2009 15:17:06 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-03
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
> Complete diff:
> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
> 
> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt

A few comments:

 - I doubt today there's ever any cases where there could confusion as
   to what channel "EXTERNAL" refers to.  The confusion and the need for
   a priori agreement is theoretical -- if so then the text should
   probably reflect that, otherwise examples should be given.

 - When "EXTERNAL" is used one would think that the highest-layer,
   innermost end-to-end channel is the one it ought to refer to.  It
   strikes me as a good idea to state that.

 - An informative reference to TLS (RFC5246) seems necessary.  (Or maybe
   even normative.)

 - The string "a002" in the example given should probably be explained,
   or even removed (it seems superfluous, besides, application protocol
   bindings of SASL are not needed in order to have an example, no?).

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LKCgqw081167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 13:12:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3LKCg0X081166; Tue, 21 Apr 2009 13:12:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LKCfgn081160 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 21 Apr 2009 13:12:42 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3LKCfwW018650 for <[e-mail]>; Tue, 21 Apr 2009 20:12:41 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LKCfu8019986 for <[e-mail]>; Tue, 21 Apr 2009 14:12:41 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LK3C0r015566 for <[e-mail]>; Tue, 21 Apr 2009 15:03:12 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LK3CRL015565 for [e-mail]; Tue, 21 Apr 2009 15:03:12 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 21 Apr 2009 15:03:12 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I forgot to set the to/cc: headers correctly before sending.  Sorry.

On Tue, Apr 21, 2009 at 02:50:36PM -0500, Nicolas Williams wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
> 
> Changes from -02:

I did forget one change, a note that the channel to be bound must be the
end-to-end secure channel at the highest possible layer.  This, and the
need for (but not the how of) channel binding type negotiation really
belong in an update to RFC5056.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LK7p19080818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 13:07:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3LK7pMQ080817; Tue, 21 Apr 2009 13:07:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LK7edh080805 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 21 Apr 2009 13:07:51 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3LK7eLt017387 for <[e-mail]>; Tue, 21 Apr 2009 20:07:40 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LK7e0O040702 for <[e-mail]>; Tue, 21 Apr 2009 14:07:40 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LJod33015549; Tue, 21 Apr 2009 14:50:39 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LJobrL015548; Tue, 21 Apr 2009 14:50:37 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 21 Apr 2009 14:50:37 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt

Changes from -02:

 - added channel binding type negotiation through pseudo-mechanism names
    - CB-tls-srv-endpoint
    - CB-tls-unique
    - If the server doesn't list any then the client assumes all channel
      binding types available on the client side are also available on
      the server side.  But the server SHOULD list them.

 - revamped the IANA section and added text re: pseudo-mechanism names
   for channel binding type negotiation

 - added security considerations text re: channel binding type
   negotiation and protection thereof

 - added reference to YAP

 - made the text more API neutral

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LK1KF5080338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 13:01:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3LK1KpN080337; Tue, 21 Apr 2009 13:01:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3LK1KB6080331 for <[e-mail]>; Tue, 21 Apr 2009 13:01:20 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 6F17028C32F; Tue, 21 Apr 2009 13:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 21 Apr 2009 13:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-03.txt
	Pages           : 10
	Date            : 2009-04-21

This document specifies the semantics of channel binding for the
Simple Authentication and Security Layers (SASL) framework,
mechanisms and applications.  This includes negotiation of channel
binding, and negotiation of channel binding types.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-channel-bindings-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3J4SEU6040605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 21:28:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3J4SE4s040604; Sat, 18 Apr 2009 21:28:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3J4S14c040504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 18 Apr 2009 21:28:13 -0700 (MST) (envelope-from [e-mail])
Received: from m90-137-102-220.cust.tele2.se ([90.137.102.220] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LvOdH-000207-S5; Sun, 19 Apr 2009 06:27:58 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090419:[e-mail]::N8vgaeH/JgY4FrQw:1M8N
X-Hashcash: 1:22:090419:[e-mail]::NQNbeOg11R1dx9lR:6Iyr
X-Hashcash: 1:22:090419:[e-mail]::xbIsk4rL1qwKTHh0:ddjN
Date: Sun, 19 Apr 2009 06:27:47 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Sat, 18 Apr 2009 06:13:39 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Apr 18, 2009, at 2:54 AM, Simon Josefsson wrote:
>
>> What problem do we want to solve by not letting IANA hand out
>> assignments on a FCFS basis?
>
> My concern is that someone will request the registration of a name in
> the family name space for a mechanism which doesn't fit well into that
> family.

Thanks for explaining, now I understand the concern better.  Still, I
don't think the human work needed to define/review instructions for
experts, assigning and replacing the expert, and dealing with the
potential of appeals, is motivated here.  The harm caused by a mistaken
registration is low.  Well intended people will listen to reason if we
can present good arguments, and eventually, we can't stop anyone from
using any mechanism name anyway.

I think the IESG have better things to do than responding to appeals
over an expert decision for this mechanism family.  The costs of IESG
appeals are high, the cost of even clearly bogus registrations is low.

The document could try to explain this issue further, and request people
more strongly to ask for review before requesting an assignment.  But I
think the current text is sufficiently clear already.

> I suspect the 7.1.1 procedures (which are FCFS) if applied here would
> likely work out okay in practice as the IANA practice seems to be "ask
> for help" in adding items to rarely used tables.  So I don't object to
> use of FCFS here.

Thanks.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IDDujn097228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 06:13:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3IDDurY097227; Sat, 18 Apr 2009 06:13:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IDDiED097206 for <[e-mail]>; Sat, 18 Apr 2009 06:13:55 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SenSBgB=[e-mail]>; Sat, 18 Apr 2009 14:13:42 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Sat, 18 Apr 2009 06:13:39 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 18, 2009, at 2:54 AM, Simon Josefsson wrote:

> What problem do we want to solve by not letting IANA hand out
> assignments on a FCFS basis?

My concern is that someone will request the registration of a name in  
the family name space for a mechanism which doesn't fit well into that  
family.  I don't think specification review is requires to address  
this concern, but I do think review of the purpose of the requested  
name for the requested purpose.  I prefer that the RFC 4422, 7.1.2  
procedures used to register a family of mechanism be used in  
registering names within that family.

I suspect the 7.1.1 procedures (which are FCFS) if applied here would  
likely work out okay in practice as the IANA practice seems to be "ask  
for help" in adding items to rarely used tables.  So I don't object to  
use of FCFS here.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ICDxoN093650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 05:13:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3ICDwch093649; Sat, 18 Apr 2009 05:13:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ICDt9X093639 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 18 Apr 2009 05:13:57 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lv9Qe-00014Q-BQ for [e-mail]; Sat, 18 Apr 2009 14:13:54 +0200
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-12.txt
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090418:[e-mail]::751W5ugb71GdM8/F:7yGE
X-Hashcash: 1:22:090418:[e-mail]::xTDiivSoRgsx7PKG:HwFI
X-Hashcash: 1:22:090418:[e-mail]::dmBdobzgkum/Bkrl:fQcb
Date: Sat, 18 Apr 2009 14:13:49 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Sat, 18 Apr 2009 04:15:01 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

> http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-12.txt

Diff available from:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-sasl-gs2-12.txt

I think the only open issue now is how the channel binding gets chosen,
but it is similar to the same issue with SCRAM.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IBGHiw089646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 04:16:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3IBGHrj089645; Sat, 18 Apr 2009 04:16:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IBGGtU089639 for <[e-mail]>; Sat, 18 Apr 2009 04:16:16 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 7DEC73A6B8F; Sat, 18 Apr 2009 04:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-gs2-12.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sat, 18 Apr 2009 04:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson, N. Williams
	Filename        : draft-ietf-sasl-gs2-12.txt
	Pages           : 22
	Date            : 2009-04-18

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of
channel binding.  Only GSS-API mechanisms that support channel
binding are supported.

See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-12.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IArjUK087554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 03:53:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3IArjbS087553; Sat, 18 Apr 2009 03:53:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IArhWQ087544 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 18 Apr 2009 03:53:44 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lv8B3-00013a-D7; Sat, 18 Apr 2009 12:53:41 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090418:[e-mail]::bwqTbxIRQkFuMgGw:v63
X-Hashcash: 1:22:090418:[e-mail]::11Ll4q5FDWLhBjEa:3Jf7
X-Hashcash: 1:22:090418:[e-mail]::xM4wdVEvDeAfmhTG:B/ER
Date: Sat, 18 Apr 2009 12:53:40 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 14 Apr 2009 12:13:43 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Apr 14, 2009 at 06:06:59PM +0100, Alexey Melnikov wrote:
>> >>>I removed the part about localization.
>> >>>
>> >No!  These are purely local localizations, not part of any protocol.
>> >There's no need to mention language tags.
>> > 
>> >
>> Well Ok. But the document still needs to say how localization is controlled.
>
> It's a _local_ matter.  Like lots of other APIs.  The localization is to
> the caller's _locale_, which is a _local_ matter.
>
> There's nothing more for the spec to say, except perhaps that the
> localization is to the caller's locale.

I've restored this part of the document.  I don't care strongly about
this feature, but it is marginally potentially useful.  Let's see if it
passes further review.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IA1re5084304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 03:01:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3IA1rpI084303; Sat, 18 Apr 2009 03:01:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3IA1ob4084295 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 18 Apr 2009 03:01:52 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lv7Mq-000133-OH; Sat, 18 Apr 2009 12:01:49 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090418:[e-mail]::1CJDME19GJkncCbv:50Lr
X-Hashcash: 1:22:090418:[e-mail]::alSZeTS19T8YyFki:JjT8
X-Hashcash: 1:22:090418:[e-mail]::HLi2J4zlgmbhIEGd:MX8w
Date: Sat, 18 Apr 2009 12:01:47 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 15 Apr 2009 10:28:04 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> I don't care strongly either.  FCFS w/ specification required (but not
> expert review, not standards action) seems like the best approach.

That would work.  It requires some effort on the person registering the
name, and anyone well intended to register a EXTERNAL-* name should be
able to spend the time to write down a specification for it.

Unfortunately RFC 5226 requires for "specification required" that the
specification is possible to implement in an interoperable way.  It also
requires a designated expert to evaluate.  That can be a quite delicate
issue, and I don't see what is gained by adding this.

The explanation in RFC 5226 for FCFS seems to describe the intent with
what you describe:

      First Come First Served - Assignments are made to anyone on a
            first come, first served basis.  There is no substantive
            review of the request, other than to ensure that it is
            well-formed and doesn't duplicate an existing assignment.
            However, requests must include a minimal amount of clerical
            information, such as a point of contact (including an email
            address) and a brief description of how the value will be
            used.  Additional information specific to the type of value
            requested may also need to be provided, as defined by the
            namespace.  For numbers, the exact value is generally
            assigned by IANA; with names, specific text strings can
            usually be requested.

            Examples: SASL mechanism names [RFC4422], LDAP Protocol
            Mechanisms, and LDAP Syntax [RFC4520].

The "brief description of how the value will be used" is the level of
detail that I believe we want to require.

Given that we already use FCFS to register SASL mechanism names, and
there haven't been any problems, I don't see any reason to use anything
more onerous to register EXTERNAL-* mechanism names.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3I9sR6x083553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 02:54:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3I9sReD083552; Sat, 18 Apr 2009 02:54:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3I9sPGM083543 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 18 Apr 2009 02:54:26 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lv7Fg-00012o-G7; Sat, 18 Apr 2009 11:54:24 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090418:[e-mail]::i0si8A+9K/l5OsOe:0BhJ
X-Hashcash: 1:22:090418:[e-mail]::lPIng8oNbBXFS7bD:2aOH
X-Hashcash: 1:22:090418:[e-mail]::/MeoxlRJUHYnF2xb:6eSI
Date: Sat, 18 Apr 2009 11:54:23 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Wed, 15 Apr 2009 09:31:32 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> Expert review is useful when it not feasible to let IANA to
> mechanically hand out assignments.

What problem do we want to solve by not letting IANA hand out
assignments on a FCFS basis?

> That is, the Reviewer should avoid reviewing the particulars of the
> mechanism and simply focus on whether the requested name is sensible
> for the requested purpose.  IANA prefers not to make such judgements,
> hence the need for Expert Review.

I don't understand how anyone can come to the conclusion that a name is
unacceptable for a purpose without reviewing the particulars of the
mechanism?  Could you give a concrete example?

The only threats I see to a FCFS approach are along these lines:

- Someone overloads IANA with one request every day
- Someone registers EXTERNAL-<offensive word>
- Someone registers EXTERNAL-<viagraspam.com>

The cost of accepting or dealing with problems like that, in the context
of registering EXTERNAL-* SASL mechanism names, appears to be low.  The
cost of implementing and handling appeals and expert review issues can
be significant and time consuming.

Again, I don't feel strongly about this, but if there is nothing else to
discuss around the draft, that seems like a good sign. ;)

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3I9h3Lj083033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Apr 2009 02:43:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3I9h3KP083032; Sat, 18 Apr 2009 02:43:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3I9gokJ083020 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 18 Apr 2009 02:43:02 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lv74R-00012j-4h; Sat, 18 Apr 2009 11:42:47 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090418:[e-mail]::qEjC++4UGL/oLqIl:BYjM
X-Hashcash: 1:22:090418:[e-mail]::rzL86tdtW7L6RxNo:01MZN
Date: Sat, 18 Apr 2009 11:42:45 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Thu, 16 Apr 2009 09:24:49 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

>> This seems to require that application supports all channel binding
>> types.
>
> No.  The application need only inquire the channel to find out the
> channel bindings for it, then it must pass them to the SASL mechanism.
>
> Nothing complicated about that.  Oh, it may require a loop, something
> like:
>
> 	foreach binding_type = channel_binding_types(channel)
> 		sasl_set_channel_binding(binding_type,
> 			channel_binding(channel, binding_type))
>
> But that does not seem too complicated to me.

The problematic part is getting the 'channel' variable.  In most cases,
it will probably be a TLS channel initiated by the same application
doing the SASL exchange.  However, it can easily be a IPSEC layer, or a
TLS-based VPN, or the new OPSEC [1] proposal.

[1] http://tools.ietf.org/search/draft-paddon-tcposp-00

>> I still think something is missing to assure interoperability.
>
> The mechanisms need to specify how a single type is to be selected.  YAP
> will always require unique channel binding types.  SCRAM will prefer
> end-point channel binding types over unique ones so as to better
> traverse concetrators.

But there is nothing that says which channel should be preferred.  There
can be multiple channels.  That is my concern.

>> What if a client support and use a channel binding for IPSEC but the
>> server support and use a channel binding for TLS?  Both sides will
>> announce and attempt to use a channel binding.  The channel binding will
>> not match, and they can't talk to each other.  Both will think there is
>> a MITM attack going on.  What prevents this from happening?
>
> (First of all, this is farfetched today.  Second, it means both must be
> using IPsec and TLS as channels (well, both must be using IPsec, though
> only one side might implement IPsec channels).)

The only farfetched about it is the part about channel bindings.  Plenty
of people use SASL in TLS over IPSEC or SSH.  What we are adding here is
a channel binding in the SASL step, so we need to be realistic about
what kind of channels are in use.

> I'd argue that we should always bind to an end-to-end channel at the
> highest possible layer below the app.

That works.

> That rule solves the interop problem by stating a global preference
> shared a priori by both sides.  It also allows us to have channel
> binding from TLS to IPsec if both sides support it.  Thus we'd have
> channel binding from SASL->TLS->IPsec and only IPsec would be
> providing session protection.

Sounds fine.

> When we worked on RFC5056 you brought up this issue and we punted, but
> now I'm convinced that the right solution is to state the "always bind
> to an end-to-end channel at the highest possible layer below the app"
> rule.

So, where do we write down this requirement?  In the GS2/SCRAM mechanism
documents, in the core SASL specification (or an update to it), or in
implementation guidance, in an clarification to RFC 5056, or somewhere
else?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3H5ZKgG083754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 22:35:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3H5ZKlj083753; Thu, 16 Apr 2009 22:35:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3H5Z8kA083735 for <[e-mail]>; Thu, 16 Apr 2009 22:35:19 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.161.138] (92.40.161.138.sub.mbb.three.co.uk [92.40.161.138])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SegVBQB=[e-mail]>; Fri, 17 Apr 2009 06:35:04 +0100
Message-ID: <[e-mail]>
Date: Fri, 17 Apr 2009 06:34:54 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Choice of channel binding types in SCRAM
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:

>Kurt Zeilenga <[e-mail]> writes:
>  
>
>>On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
>>    
>>
>>>If you were to propose adding the channel binding types to the
>>>mechanism
>>>names (well, suitably compressed to fit in the 20 char SASL mech name
>>>limit), I could go along with that.
>>>      
>>>
>>While not a perfect solution (I don't think a perfect solution
>>exists), I willing to go along with this... as I can simply ignore the
>>end-point variant.
>>    
>>
>That would work for me as well.  I don't see any reason to implement the
>tls-server-end-point channel binding as it only works with X.509 server
>certs whereas tls-unique always works.
>
>I share Kurt's concern that
>these channel binding trade-offs may make the system brittle.
>  
>
+1



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GMdskr062368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 15:39:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GMdsPB062367; Thu, 16 Apr 2009 15:39:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GMdfEp062334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 16 Apr 2009 15:39:53 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LuaF8-00007o-OH; Fri, 17 Apr 2009 00:39:39 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Choice of channel binding types in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090416:[e-mail]::VocD6nEEKfhpbsee:nIV
X-Hashcash: 1:22:090416:[e-mail]::/wxREZsmtbHqbHTs:FbsT
X-Hashcash: 1:22:090416:[e-mail]::nlkgsJwBe/a561sT:gj/K
Date: Fri, 17 Apr 2009 00:39:36 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Thu, 16 Apr 2009 12:55:32 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
>> If you were to propose adding the channel binding types to the
>> mechanism
>> names (well, suitably compressed to fit in the 20 char SASL mech name
>> limit), I could go along with that.
>
> While not a perfect solution (I don't think a perfect solution
> exists), I willing to go along with this... as I can simply ignore the
> end-point variant.

That would work for me as well.  I don't see any reason to implement the
tls-server-end-point channel binding as it only works with X.509 server
certs whereas tls-unique always works.  I share Kurt's concern that
these channel binding trade-offs may make the system brittle.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GKFEh9054191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 13:15:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GKFEBL054190; Thu, 16 Apr 2009 13:15:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GKF4lG054174 for <[e-mail]>; Thu, 16 Apr 2009 13:15:14 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GKF3Ip003495 for <[e-mail]>; Thu, 16 Apr 2009 20:15:03 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3GKF3Ou037909 for <[e-mail]>; Thu, 16 Apr 2009 14:15:03 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3GK5af3012676; Thu, 16 Apr 2009 15:05:36 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GK5aTh012675; Thu, 16 Apr 2009 15:05:36 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 16 Apr 2009 15:05:36 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: Choice of channel binding types in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 16, 2009 at 12:55:32PM -0700, Kurt Zeilenga wrote:
> 
> On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
> >If you were to propose adding the channel binding types to the  
> >mechanism
> >names (well, suitably compressed to fit in the 20 char SASL mech name
> >limit), I could go along with that.
> 
> While not a perfect solution (I don't think a perfect solution  
> exists), I willing to go along with this... as I can simply ignore the  
> end-point variant.

Another possibility is to have a pair of magic mechanism names to
negotiate the use of one or another channel binding type independently
of mechanism name, with reasonable defaults for when these are missing
from the server's mech list.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GJtmxv052844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 12:55:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GJtmcD052843; Thu, 16 Apr 2009 12:55:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GJtapf052837 for <[e-mail]>; Thu, 16 Apr 2009 12:55:47 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeeNNwB=[e-mail]>; Thu, 16 Apr 2009 20:55:35 +0100
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Choice of channel binding types in SCRAM
Date: Thu, 16 Apr 2009 12:55:32 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
> If you were to propose adding the channel binding types to the  
> mechanism
> names (well, suitably compressed to fit in the 20 char SASL mech name
> limit), I could go along with that.

While not a perfect solution (I don't think a perfect solution  
exists), I willing to go along with this... as I can simply ignore the  
end-point variant.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GHG9CZ041958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 10:16:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GHG9jO041957; Thu, 16 Apr 2009 10:16:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GHFw2u041943 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 16 Apr 2009 10:16:08 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3GHFw3v021119 for <[e-mail]>; Thu, 16 Apr 2009 17:15:58 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 n3GHFvVS026731 for <[e-mail]>; Thu, 16 Apr 2009 11:15:57 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3GH6VKb012485; Thu, 16 Apr 2009 12:06:31 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GH6VGo012484; Thu, 16 Apr 2009 12:06:31 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 16 Apr 2009 12:06:31 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: Choice of channel binding types in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 16, 2009 at 09:15:00AM -0700, Kurt Zeilenga wrote:
> The selection of channel binding in SCRAM is client choice.  A client  
> may for various reasons be unwilling or unable to produce a end-point  
> channel binding.  A client ought to always use a unique channel  
> binding type and, server willing, bind to the channel, and a server  
> which willing to accept an end-point binding ought to willing to  
> accept a unique channel binding instead.  If this is not the case, it  
> would to create a very brittle system.

The client ought to always be able to use one type in particular or else
another.  And so far we'd been working with "tls-server-end-point" as
the preference.

> In short, at present, I think I favor allowing only unique channel  
> bindings in SCRAM.

Support for concentrators is crucial to deployment.  I don't see how we
can ignore concentrators.

If you were to propose adding the channel binding types to the mechanism
names (well, suitably compressed to fit in the 20 char SASL mech name
limit), I could go along with that.  Giving up on concentrators is just
not an option without first hearing from concentrator implementors
(also, I'm pretty sure that Chris would object).

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GH59Ta041014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 10:05:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GH599t041013; Thu, 16 Apr 2009 10:05:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GH58xR041006 for <[e-mail]>; Thu, 16 Apr 2009 10:05:08 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GH58PC001678 for <[e-mail]>; Thu, 16 Apr 2009 17:05:08 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 n3GH57ih061309 for <[e-mail]>; Thu, 16 Apr 2009 11:05:07 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3GGmB8U012467; Thu, 16 Apr 2009 11:48:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GGmBq0012466; Thu, 16 Apr 2009 11:48:11 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 16 Apr 2009 11:48:11 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 16, 2009 at 09:46:11AM -0700, Kurt Zeilenga wrote:
> I did read it carefully.  What you miss is that my concern is not just  
> about YAP, it's about undue restrictions upon future mechanisms...
> 
>   The document precludes, for instance, a mechanism design in which  
> different name for each type of channel binding the server is willing  
> to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").

How does it do that?  Are we not free to add more rules later?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGkSl7039775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:46:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GGkRAn039774; Thu, 16 Apr 2009 09:46:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGkGLf039758 for <[e-mail]>; Thu, 16 Apr 2009 09:46:27 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <Sedg1gB=[e-mail]>; Thu, 16 Apr 2009 17:46:15 +0100
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 09:46:11 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 16, 2009, at 9:13 AM, Nicolas Williams wrote:

>
> On Thu, Apr 16, 2009 at 09:03:20AM -0700, Kurt Zeilenga wrote:
>> On Apr 16, 2009, at 7:45 AM, Nicolas Williams wrote:
>>> I actually changed that in -02 since that makes no sense for YAP.
>>> Please look at -02.
>>
>> The above text is from -02.  As is the IANA consideration:
>>  Henceforth any SASL mechanism registration MUST indicate ... two
>> mechanism names and an indication of which name indicates
>> server support for channel binding.
>
> Read carefully:
>
>    "...and, if the mechanism supports optional channel binding then c)
>    two mechanism names and an indication of which name indicates  
> server
>    support for channel binding."
>
> Note the "and, if..." clause.


I did read it carefully.  What you miss is that my concern is not just  
about YAP, it's about undue restrictions upon future mechanisms...

   The document precludes, for instance, a mechanism design in which  
different name for each type of channel binding the server is willing  
to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGWCUC038867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:32:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GGWCPM038866; Thu, 16 Apr 2009 09:32:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGWA5b038859 for <[e-mail]>; Thu, 16 Apr 2009 09:32:11 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeddhwB=[e-mail]>; Thu, 16 Apr 2009 17:32:09 +0100
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 09:32:04 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 16, 2009, at 8:58 AM, Kurt Zeilenga wrote:

>>
>>
>> - Mechanisms that support channel bindings MUST protect the  
>> negotiation
>> of channel bindings, to prevent CB downgrade.
>
> My view is that each name refers to a mechanism.  That is, SCRAM- 
> SHA256 and SCRAM-SHA256-PLUS are two different SASL mechanisms based  
> upon the same technology, and that downgrade between them is very  
> similar to say downgrade between DIGEST-MD5 and YAP.  What we need  
> is general downgrade protection.  We already have some facilities  
> for downgrade protection.  I much rather see (in RFC 4422)  
> enhancements to the general downgrade protections than per-security  
> feature downgrade protection schemes.

Let me come at this yet another way.

Say there were mechanisms called "SCRAM-SHA256-INT" and "SCRAM-SHA256- 
INT-CONF", where both were "SCRAM-SHA256" but established (non- 
optionally) security layers, the former with just integrity protection  
and the latter with both integrity and confidentiality protection.

When a server offers "SCRAM-SHA256" as well as one or both of the  
above, there is a downgrade attack issue in the mechanism negotiation.

This issue seems to me to be not significantly different than the  
"SCRAM-SHA256" and "SCRAM-SHA256-PLUS" downgrade issue, or the DIGEST- 
MD5 vs YAP downgrade issue for that matter.

If you think they are significant different, can you explain how?

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGUYbK038721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:30:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GGUXDM038719; Thu, 16 Apr 2009 09:30:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGUXAQ038712 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 16 Apr 2009 09:30:33 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3GGUW3X003742 for <[e-mail]>; Thu, 16 Apr 2009 16:30: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 n3GGUWfR050690 for <[e-mail]>; Thu, 16 Apr 2009 10:30:32 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3GGDaYR012389; Thu, 16 Apr 2009 11:13:36 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GGDatk012388; Thu, 16 Apr 2009 11:13:36 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 16 Apr 2009 11:13:36 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 16, 2009 at 09:03:20AM -0700, Kurt Zeilenga wrote:
> On Apr 16, 2009, at 7:45 AM, Nicolas Williams wrote:
> >I actually changed that in -02 since that makes no sense for YAP.
> >Please look at -02.
> 
> The above text is from -02.  As is the IANA consideration:
>   Henceforth any SASL mechanism registration MUST indicate ... two  
> mechanism names and an indication of which name indicates
> server support for channel binding.

Read carefully:

    "...and, if the mechanism supports optional channel binding then c)
    two mechanism names and an indication of which name indicates server
    support for channel binding."

Note the "and, if..." clause.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGTK4s038610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:29:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GGTKUc038609; Thu, 16 Apr 2009 09:29:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGTJEp038602 for <[e-mail]>; Thu, 16 Apr 2009 09:29:20 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GGTJR9011514 for <[e-mail]>; Thu, 16 Apr 2009 16:29:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3GGTJ6Y049246 for <[e-mail]>; Thu, 16 Apr 2009 10:29:19 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3GGCNd4012382; Thu, 16 Apr 2009 11:12:23 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GGCNpw012381; Thu, 16 Apr 2009 11:12:23 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 16 Apr 2009 11:12:23 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 16, 2009 at 08:58:04AM -0700, Kurt Zeilenga wrote:
> then the IANA consideration section should also be reworded.  (The  
> existence of two MUSTs here lead me to conclude something quite  
> different about the intent.)

Read your e-mail.  It has been updated already in -02.

> >Note that while I could see a use for a model where you negotiate  
> >unique vs endpoint vs no channel bindings, I'd rather not pull into  
> >SASL negotation the question of which channel to bind to.
> 
> A client does not know what server channel binding types the server  
> accepts.  For instance, a server might be generally willing to accept  
> unique channel bindings but never end-point channel bindings (because  
> it does trust the client (and its user) to establish them (in eyes of  
> the server) appropriately.

I'm effectively saying that the server must each kind of channel binding
when feasible.  Therefore YAP can always be available when TLS is used
UNLESS there is a TLS concentrator which does not have a way of
communicating the unique channel bindings to the server, or UNLESS the
server's TLS implementation doesn't support getting the tls-unique
bindings.  (TLS concentrators are the reason we prefer end-point channel
bindings over unique.)

> >- Mechanisms that are capable of protecting the mechanism negotation
> >should do so, to prevent mechanism downgrades.  Yes, this should apply
> >to _all_ mechanisms, and is independent of CB.
> 
> I would be interested in discussing this further in the context of RFC  
> 4422 revision (that is, as changes to 4422bis I-D).

I recently proposed something along these lines, then withdrew my
proposal.  See that reply.

> >- Mechanisms that support channel bindings MUST protect the  
> >negotiation
> >of channel bindings, to prevent CB downgrade.
> 
> My view is that each name refers to a mechanism.  That is, SCRAM- 
> SHA256 and SCRAM-SHA256-PLUS are two different SASL mechanisms based  
> upon the same technology, and that downgrade between them is very  
> similar to say downgrade between DIGEST-MD5 and YAP.  What we need is  
> general downgrade protection.  We already have some facilities for  
> downgrade protection.  I much rather see (in RFC 4422) enhancements to  
> the general downgrade protections than per-security feature downgrade  
> protection schemes.

The only negotiation mechanism we have now is mechanism negotiation (heh).

Adding new negotiations that are NOT done through mechanism negotiation
is a recipe for failure because it means doing changes to all
application protocols.  If you want to prevent deployment, then insist
on this.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGFAIA037586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:15:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GGF9Cf037585; Thu, 16 Apr 2009 09:15:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GGF87E037578 for <[e-mail]>; Thu, 16 Apr 2009 09:15:09 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SedZhgB=[e-mail]> for <[e-mail]>; Thu, 16 Apr 2009 17:15:03 +0100
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
Subject: Choice of channel binding types in SCRAM
Date: Thu, 16 Apr 2009 09:15:00 -0700
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The selection of channel binding in SCRAM is client choice.  A client  
may for various reasons be unwilling or unable to produce a end-point  
channel binding.  A client ought to always use a unique channel  
binding type and, server willing, bind to the channel, and a server  
which willing to accept an end-point binding ought to willing to  
accept a unique channel binding instead.  If this is not the case, it  
would to create a very brittle system.

Client developers generally like keep things simple.  Adding support  
for end-point types could be viewed by the client developer as an  
unnecessary complication.  It seems likely that client developers  
would simply not code support for end-point types.

Of course, some client developers might see some value in supporting  
end-point types and implement support for them.

By definition, a end-point binding is to be securely bound to the  
channel.  There have been some interesting discussions on and off list  
concerning the implications of self-signed certificates.  It was  
suggested that establishment of the end-point binding might involve  
user interfaces and this has some significant implications.

As a server developer, while I am somewhat concern that client  
developers won't well implement end-point channel bindings, I would be  
quite concerned if the creation of end-point channel bindings ever  
involved user interactions.  Such concerns might lead servers which  
reject end-point bindings.  And that in turn would lead to more client  
developers avoiding use of end-point bindings.

While I understand that end point bindings may be more TLS  
concentrator friendly, but to avoid creating a brittle system, this  
unfriendliness of unique bindings to TLS concentrators must be  
overcome OR we need to remove them from consideration.

In short, at present, I think I favor allowing only unique channel  
bindings in SCRAM.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GG3QEp035962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:03:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GG3QEE035961; Thu, 16 Apr 2009 09:03:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GG3PDx035953 for <[e-mail]>; Thu, 16 Apr 2009 09:03:25 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SedWywB=[e-mail]>; Thu, 16 Apr 2009 17:03:23 +0100
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 09:03:20 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 16, 2009, at 7:45 AM, Nicolas Williams wrote:

>
> On Thu, Apr 16, 2009 at 07:17:08AM -0700, Kurt Zeilenga wrote:
>> On Apr 16, 2009, at 6:45 AM, Jeffrey Hutzelman wrote:
>>> You keep bringing this up, but it's a red herring.  Nico's document
>>> doesn't mandate that approach; it recommends it,
>>
>> The document says:
>>   The convention is that the specification for any SASL mechanism
>> that supports optional channel binding MUST specify two mechanism  
>> names
>> The document does only recommend a naming scheme.
>> The document precludes, for instance, a mechanism design in which
>> different name for each type of channel binding the server is willing
>> to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").
>
> I actually changed that in -02 since that makes no sense for YAP.
> Please look at -02.

The above text is from -02.  As is the IANA consideration:
   Henceforth any SASL mechanism registration MUST indicate ... two  
mechanism names and an indication of which name indicates
server support for channel binding.

>>> and mandates that mechanisms with optional channel binding support
>>> protect the negotiation.
>>
>> His document says
>>   Use of channel binding must be negotiable.
>>
>> I certain think we'll have mechanisms where use of channel binding is
>> non-negotiable.  YAP for instance is such a mechanism.
>
> I've fixed this for YAP in -02.

This text is also from -02.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GFwBwY035512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 08:58:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GFwBIN035511; Thu, 16 Apr 2009 08:58:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GFw9us035503 for <[e-mail]>; Thu, 16 Apr 2009 08:58:10 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SedVjwB=[e-mail]>; Thu, 16 Apr 2009 16:58:08 +0100
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 08:58:04 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 16, 2009, at 7:35 AM, Jeffrey Hutzelman wrote:

>
> --On Thursday, April 16, 2009 07:17:08 AM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>> The document says:
>>    The convention is that the specification for any SASL mechanism  
>> that
>> supports optional channel binding MUST specify two mechanism names
>> The document does only recommend a naming scheme.
>> The document precludes, for instance, a mechanism design in which
>> different name for each type of channel binding the server is  
>> willing to
>> accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").
>
> Yeah, that's too narrow.  The intent here was to make it clear that  
> negotiation of whether CB is used has to happen during mechanism  
> negotiation, not after a mechanism has been selected.  The two-mech- 
> name approach really should only be a recommendation.

then the IANA consideration section should also be reworded.  (The  
existence of two MUSTs here lead me to conclude something quite  
different about the intent.)

While I intend to await changes to the proposal before responding to  
all of your comments, I do have a few things I think to say now.


>
>
> Note that while I could see a use for a model where you negotiate  
> unique vs endpoint vs no channel bindings, I'd rather not pull into  
> SASL negotation the question of which channel to bind to.

A client does not know what server channel binding types the server  
accepts.  For instance, a server might be generally willing to accept  
unique channel bindings but never end-point channel bindings (because  
it does trust the client (and its user) to establish them (in eyes of  
the server) appropriately.

>
>
>> There is a general interoperability consideration here.   
>> Implementations
>> should not start a mechanism exchange which they cannot possibly
>> complete.  This is not unique to mechanisms that support CB.
>
> Sure, but you only "cannot possibly complete" if you don't support  
> _anything_.  If you support anything at all, then there is the  
> possibility that the peer also supports that, and you can't know  
> until you start negotiation.

In general, the exchange just fails leaving the client will little  
clue as to what went wrong.  The client's user and the server operator  
chat, reach some agreement, and the client tries again.

I suspect this will be so with CB.  In the above for instance, the  
server operator is just going to tell the client's user to "use unique  
bindings".

> The interoperability concern is requiring negotiation of the use of  
> CB to happen at the same time as negotiation of mechanism, so that  
> you don't end up selecting a mechanism for which you want channel  
> bindings and then discovering you don't actually have CB data to use.

Having some CB data may very well be not the right CB data for the  
exchange, so you end up having a prior agreements anyways.

Seems much like problems we've seen before.  I still don't see  
anything so new here to "require" change to RFC 4422.

>
>
>
>>> and there is a clear security reason for requiring the negotiation
>>> to be protected to avoid a downgrade.
>>
>> I don't see the downgrade attack issues with CB to be significantly
>> different from downgrade attack of various other (security)  
>> features that
>> might be selectable via mechanism name.  So I think that any
>> consideration here could and should be generalized.
>
> Well, there are two considerations here...
>
> - Mechanisms that are capable of protecting the mechanism negotation
> should do so, to prevent mechanism downgrades.  Yes, this should apply
> to _all_ mechanisms, and is independent of CB.

I would be interested in discussing this further in the context of RFC  
4422 revision (that is, as changes to 4422bis I-D).

>
> - Mechanisms that support channel bindings MUST protect the  
> negotiation
> of channel bindings, to prevent CB downgrade.

My view is that each name refers to a mechanism.  That is, SCRAM- 
SHA256 and SCRAM-SHA256-PLUS are two different SASL mechanisms based  
upon the same technology, and that downgrade between them is very  
similar to say downgrade between DIGEST-MD5 and YAP.  What we need is  
general downgrade protection.  We already have some facilities for  
downgrade protection.  I much rather see (in RFC 4422) enhancements to  
the general downgrade protections than per-security feature downgrade  
protection schemes.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GF2Ip8031441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 08:02:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GF2IhQ031440; Thu, 16 Apr 2009 08:02:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GF27Jp031427 for <[e-mail]>; Thu, 16 Apr 2009 08:02:18 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GF27ti022156 for <[e-mail]>; Thu, 16 Apr 2009 15:02:07 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3GF275m018285 for <[e-mail]>; Thu, 16 Apr 2009 09:02:07 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3GEjBmg012253; Thu, 16 Apr 2009 09:45:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GEj8ih012252; Thu, 16 Apr 2009 09:45:08 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 16 Apr 2009 09:45:08 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 16, 2009 at 07:17:08AM -0700, Kurt Zeilenga wrote:
> On Apr 16, 2009, at 6:45 AM, Jeffrey Hutzelman wrote:
> >You keep bringing this up, but it's a red herring.  Nico's document  
> >doesn't mandate that approach; it recommends it,
> 
> The document says:
>    The convention is that the specification for any SASL mechanism  
> that supports optional channel binding MUST specify two mechanism names
> The document does only recommend a naming scheme.
> The document precludes, for instance, a mechanism design in which  
> different name for each type of channel binding the server is willing  
> to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").

I actually changed that in -02 since that makes no sense for YAP.
Please look at -02.

> >and mandates that mechanisms with optional channel binding support  
> >protect the negotiation.
> 
> His document says
>    Use of channel binding must be negotiable.
> 
> I certain think we'll have mechanisms where use of channel binding is  
> non-negotiable.  YAP for instance is such a mechanism.

I've fixed this for YAP in -02.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEjuXX030186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 07:45:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GEjumh030184; Thu, 16 Apr 2009 07:45:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEjsp6030158 for <[e-mail]>; Thu, 16 Apr 2009 07:45:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SedEoAB=[e-mail]>; Thu, 16 Apr 2009 15:45:53 +0100
Cc: Jeffrey Hutzelman <[e-mail]>, Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 07:45:49 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 16, 2009, at 7:23 AM, Alexey Melnikov wrote:

>
> Kurt Zeilenga wrote:
> [...]
>
>> As RFC 4422 doesn't itself attempt to abstract away the  
>> differences  between mechanisms, it can and should remain mum here.
>
> I actually disagree. When I think about SASL I am thinking about  
> such abstraction.
> For example a protocol service name is a part of this abstraction,  
> even though mechanism are not required to use it. Authorization  
> identity is another part.

I'm guilty of not precisely wording my statement.

RFC 4422 doesn't generally hide the differences in mechanisms from  
protocol implementations nor hides the differences in protocols from  
mechanism implementations.

RFC 4422 certainly does try to hide the difference in mechanism from  
protocol specifications and vice versa.

I haven't see any comment what so ever that the suggested changes have  
any impact whatsoever on protocol specifications.

>
>
>> Likewise, RFC 4422 ought not try to abstract away the differences  
>> in  mechanisms that support channel bindings.  For instance,  
>> presently the  suggestion is mandate two names per mechanisms.
>
> I disagree with your first statement in this paragraph, but I am  
> agreeing with the second.
>
>> But what if tomorrow  we find this isn't good enough.  We'd have to  
>> update RFC 4422 to allow  introduction of something which was just  
>> because we were short-sighted  today.
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEZwXf029235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 07:35:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GEZwD9029234; Thu, 16 Apr 2009 07:35:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEZvtZ029226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 16 Apr 2009 07:35:57 -0700 (MST) (envelope-from [e-mail])
Received: from ATLANTIS.WV.CS.CMU.EDU (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3GEZs6m003905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 10:35:55 -0400 (EDT)
Date: Thu, 16 Apr 2009 10:35:54 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
cc: Nicolas Williams <[e-mail]>, [e-mail], [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, April 16, 2009 07:17:08 AM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

> The document says:
>     The convention is that the specification for any SASL mechanism that
> supports optional channel binding MUST specify two mechanism names
> The document does only recommend a naming scheme.
> The document precludes, for instance, a mechanism design in which
> different name for each type of channel binding the server is willing to
> accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").

Yeah, that's too narrow.  The intent here was to make it clear that 
negotiation of whether CB is used has to happen during mechanism 
negotiation, not after a mechanism has been selected.  The two-mech-name 
approach really should only be a recommendation.

Note that while I could see a use for a model where you negotiate unique vs 
endpoint vs no channel bindings, I'd rather not pull into SASL negotation 
the question of which channel to bind to.  This is different from the 
EXTERNAL-* mechanisms, where we're negotiating which channel (or channel 
type, anyway) to pull authentication information from.  That's appropriate, 
because deciding on the source of authentication information is the purpose 
of the SASL mechanism negotiation.




>> and mandates that mechanisms with optional channel binding support
>> protect the negotiation.
>
> His document says
>     Use of channel binding must be negotiable.
>
> I certain think we'll have mechanisms where use of channel binding is
> non-negotiable.  YAP for instance is such a mechanism.

Again, this is just poor language.  The goal is that when the mechanism 
supports optional channel binding, it must be possible to negotiate whether 
CB is used, rather than the endpoints having to know a priori.  Where the 
mechanism requires CB, or does not support it at all, there is nothing to 
negotiate.

We should fix the language so it's clear that the requirement for 
negotiability applies only when there is actually a choice to be made.


> There is a general interoperability consideration here.  Implementations
> should not start a mechanism exchange which they cannot possibly
> complete.  This is not unique to mechanisms that support CB.

Sure, but you only "cannot possibly complete" if you don't support 
_anything_.  If you support anything at all, then there is the possibility 
that the peer also supports that, and you can't know until you start 
negotiation.

The interoperability concern is requiring negotiation of the use of CB to 
happen at the same time as negotiation of mechanism, so that you don't end 
up selecting a mechanism for which you want channel bindings and then 
discovering you don't actually have CB data to use.


>> and there is a clear security reason for requiring the negotiation
>> to be protected to avoid a downgrade.
>
> I don't see the downgrade attack issues with CB to be significantly
> different from downgrade attack of various other (security) features that
> might be selectable via mechanism name.  So I think that any
> consideration here could and should be generalized.

Well, there are two considerations here...

- Mechanisms that are capable of protecting the mechanism negotation
  should do so, to prevent mechanism downgrades.  Yes, this should apply
  to _all_ mechanisms, and is independent of CB.
- Mechanisms that support channel bindings MUST protect the negotiation
  of channel bindings, to prevent CB downgrade.

Interestingly, if you do the first, and require that CB negotiation happen 
as part of mechanism negotiation, then you get the second for free, 
including preventing an attacker from subverting a channel by forcing you 
to downgrade to a mechanism that doesn't support CB.

The reason the latter is so important is because we want a client to be 
able to has a policy that says it is willing to ignore CB when the server 
cannot support them, but not when the server _can_ support them and an 
attacker wants to subvert the channel.  This is a transition strategy; the 
idea is that if you're using TLS, you really want CB, but the server might 
not have access to an API that provides the CB data, so you might have to 
settle for no CB.  You don't want the interoperability feature to create a 
security weakness.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEYjwX029131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 07:34:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GEYjdk029130; Thu, 16 Apr 2009 07:34:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEYHa7029089 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 16 Apr 2009 07:34:27 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3GEYGJO021296 for <[e-mail]>; Thu, 16 Apr 2009 14:34: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 n3GEYGAp062624 for <[e-mail]>; Thu, 16 Apr 2009 08:34:16 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3GEOoLC012172; Thu, 16 Apr 2009 09:24:50 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3GEOnYE012171; Thu, 16 Apr 2009 09:24:49 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 16 Apr 2009 09:24:49 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 16, 2009 at 11:04:28AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > I've updated the I-D:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-02.txt
> 
> Is the following part realistic?
> 
>    In order to use SASL [RFC4422] with channel binding [RFC5056] the
>    client and server applications MUST provide the SASL mechanism with
>    channel bindings data and channel binding type names for all
>    available channel binding types for the channel to be bound.  These
>    channel bindings data MUST be provided to the mechanism before the
>    first authentication message is produced or consumed by the
>    mechanism.

Yes, it is.

> This seems to require that application supports all channel binding
> types.

No.  The application need only inquire the channel to find out the
channel bindings for it, then it must pass them to the SASL mechanism.

Nothing complicated about that.  Oh, it may require a loop, something
like:

	foreach binding_type = channel_binding_types(channel)
		sasl_set_channel_binding(binding_type,
			channel_binding(channel, binding_type))

But that does not seem too complicated to me.

> To fix this, how about replacing "available" with "available and
> supported"?  That suggests applications need to decide which channel
> bindings they want to support.

No, "available" here means "the channel has bindings for that type."
"Supported by the channel" is implied.  "Supported by the application"
is unnecessary -- the application need not actually understand any of
the channel binding types itself.

> I still think something is missing to assure interoperability.

The mechanisms need to specify how a single type is to be selected.  YAP
will always require unique channel binding types.  SCRAM will prefer
end-point channel binding types over unique ones so as to better
traverse concetrators.

> What if a client support and use a channel binding for IPSEC but the
> server support and use a channel binding for TLS?  Both sides will
> announce and attempt to use a channel binding.  The channel binding will
> not match, and they can't talk to each other.  Both will think there is
> a MITM attack going on.  What prevents this from happening?

(First of all, this is farfetched today.  Second, it means both must be
using IPsec and TLS as channels (well, both must be using IPsec, though
only one side might implement IPsec channels).)

I'd argue that we should always bind to an end-to-end channel at the
highest possible layer below the app.  That rule solves the interop
problem by stating a global preference shared a priori by both sides.
It also allows us to have channel binding from TLS to IPsec if both
sides support it.  Thus we'd have channel binding from SASL->TLS->IPsec
and only IPsec would be providing session protection.

When we worked on RFC5056 you brought up this issue and we punted, but
now I'm convinced that the right solution is to state the "always bind
to an end-to-end channel at the highest possible layer below the app"
rule.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GENx36028205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 07:23:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GENx2j028204; Thu, 16 Apr 2009 07:23:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GENvIw028198 for <[e-mail]>; Thu, 16 Apr 2009 07:23:58 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <Sec=fAB=[e-mail]>; Thu, 16 Apr 2009 15:23:56 +0100
Message-ID: <[e-mail]>
Date: Thu, 16 Apr 2009 15:23:54 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Kurt Zeilenga <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:
 [...]

> As RFC 4422 doesn't itself attempt to abstract away the differences  
> between mechanisms, it can and should remain mum here.

I actually disagree. When I think about SASL I am thinking about such 
abstraction.
For example a protocol service name is a part of this abstraction, even 
though mechanism are not required to use it. Authorization identity is 
another part.

> Likewise, RFC 4422 ought not try to abstract away the differences in  
> mechanisms that support channel bindings.  For instance, presently 
> the  suggestion is mandate two names per mechanisms.

I disagree with your first statement in this paragraph, but I am 
agreeing with the second.

> But what if tomorrow  we find this isn't good enough.  We'd have to 
> update RFC 4422 to allow  introduction of something which was just 
> because we were short-sighted  today.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEHHSt027834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 07:17:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GEHHd9027833; Thu, 16 Apr 2009 07:17:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GEHFZj027825 for <[e-mail]>; Thu, 16 Apr 2009 07:17:16 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <Sec95wB=[e-mail]>; Thu, 16 Apr 2009 15:17:13 +0100
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 07:17:08 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 16, 2009, at 6:45 AM, Jeffrey Hutzelman wrote:

>
> --On Thursday, April 16, 2009 06:31:58 AM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>> Likewise, RFC 4422 ought not try to abstract away the differences in
>> mechanisms that support channel bindings.  For instance, presently  
>> the
>> suggestion is mandate two names per mechanisms.  But what if  
>> tomorrow we
>> find this isn't good enough.  We'd have to update RFC 4422 to allow
>> introduction of something which was just because we were short- 
>> sighted
>> today.
>
> You keep bringing this up, but it's a red herring.  Nico's document  
> doesn't mandate that approach; it recommends it,

The document says:
    The convention is that the specification for any SASL mechanism  
that supports optional channel binding MUST specify two mechanism names
The document does only recommend a naming scheme.
The document precludes, for instance, a mechanism design in which  
different name for each type of channel binding the server is willing  
to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").
> and mandates that mechanisms with optional channel binding support  
> protect the negotiation.

His document says
    Use of channel binding must be negotiable.

I certain think we'll have mechanisms where use of channel binding is  
non-negotiable.  YAP for instance is such a mechanism.

> I think those restrictions are entirely appropriate; there is an  
> interoperability reason for having the CB negotiation happen at the  
> same time as the mechanism negotiation,

There is a general interoperability consideration here.   
Implementations should not start a mechanism exchange which they  
cannot possibly complete.  This is not unique to mechanisms that  
support CB.

> and there is a clear security reason for requiring the negotiation  
> to be protected to avoid a downgrade.

I don't see the downgrade attack issues with CB to be significantly  
different from downgrade attack of various other (security) features  
that might be selectable via mechanism name.  So I think that any  
consideration here could and should be generalized.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GDjTuE025149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 06:45:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GDjTtH025148; Thu, 16 Apr 2009 06:45:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GDjIqR025130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 16 Apr 2009 06:45:29 -0700 (MST) (envelope-from [e-mail])
Received: from ATLANTIS.WV.CS.CMU.EDU (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3GDjEVd001561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 09:45:14 -0400 (EDT)
Date: Thu, 16 Apr 2009 09:45:14 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, April 16, 2009 06:31:58 AM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

> Likewise, RFC 4422 ought not try to abstract away the differences in
> mechanisms that support channel bindings.  For instance, presently the
> suggestion is mandate two names per mechanisms.  But what if tomorrow we
> find this isn't good enough.  We'd have to update RFC 4422 to allow
> introduction of something which was just because we were short-sighted
> today.

You keep bringing this up, but it's a red herring.  Nico's document doesn't 
mandate that approach; it recommends it, and mandates that mechanisms with 
optional channel binding support protect the negotiation.  I think those 
restrictions are entirely appropriate; there is an interoperability reason 
for having the CB negotiation happen at the same time as the mechanism 
negotiation, and there is a clear security reason for requiring the 
negotiation to be protected to avoid a downgrade.

-- jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GDWRNQ024077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 06:32:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3GDWQ4S024076; Thu, 16 Apr 2009 06:32:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3GDWDnW024052 for <[e-mail]>; Thu, 16 Apr 2009 06:32:25 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeczVQB=[e-mail]>; Thu, 16 Apr 2009 14:32:10 +0100
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>, Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 06:31:58 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 14, 2009, at 4:24 PM, Kurt Zeilenga wrote:

> It is the nature of SASL that such introductions will likely have an  
> impact upon implementation-specific abstractions to hide the details  
> of mechanisms from protocol implementations.

For instance, RFC 4422 is mum on the need for a framework  
implementations to manage information about identities established a  
lower level in order to support EXTERNAL.   And with the introduction  
of EXTERNAL-*, the framework implementations will likely need to  
change.  Instead of managing a single external identity (as most  
seemed to have done), they will need to manage one per each of the  
EXTERNAL-* variants.  Today, it seems that the community thinks this  
will be enough.  But our crystal ball in not 100% clear.  Maybe in 5  
years, someone will want to introduce a mechanism that requires  
framework implementations to provide something different.

As RFC 4422 doesn't itself attempt to abstract away the differences  
between mechanisms, it can and should remain mum here.

Likewise, RFC 4422 ought not try to abstract away the differences in  
mechanisms that support channel bindings.  For instance, presently the  
suggestion is mandate two names per mechanisms.  But what if tomorrow  
we find this isn't good enough.  We'd have to update RFC 4422 to allow  
introduction of something which was just because we were short-sighted  
today.

I do think it appropriate to encourage future mechanisms to be similar  
to existing mechanisms where sensible.  What I object to is us  
mandating future mechanisms be the same in area based upon what we  
think is sensible today.

RFC 4422, I think, tries very hard to leave the future open.  This  
proposal, I think, tries very hard to close our future.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3G94jV2098572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 02:04:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3G94jHT098571; Thu, 16 Apr 2009 02:04:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3G94WNT098553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 16 Apr 2009 02:04:44 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LuNWH-0007mj-8c; Thu, 16 Apr 2009 11:04:30 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090416:[e-mail]::5Eg9dxOSFJWAO5z5:6Xjl
X-Hashcash: 1:22:090416:[e-mail]::+QaPZX4eAJ9I9uke:89iY
Date: Thu, 16 Apr 2009 11:04:28 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 15 Apr 2009 12:22:18 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> I've updated the I-D:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-02.txt

Is the following part realistic?

   In order to use SASL [RFC4422] with channel binding [RFC5056] the
   client and server applications MUST provide the SASL mechanism with
   channel bindings data and channel binding type names for all
   available channel binding types for the channel to be bound.  These
   channel bindings data MUST be provided to the mechanism before the
   first authentication message is produced or consumed by the
   mechanism.

This seems to require that application supports all channel binding
types.

To fix this, how about replacing "available" with "available and
supported"?  That suggests applications need to decide which channel
bindings they want to support.

I still think something is missing to assure interoperability.

What if a client support and use a channel binding for IPSEC but the
server support and use a channel binding for TLS?  Both sides will
announce and attempt to use a channel binding.  The channel binding will
not match, and they can't talk to each other.  Both will think there is
a MITM attack going on.  What prevents this from happening?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FMaTKI067068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 15:36:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FMaTch067067; Wed, 15 Apr 2009 15:36:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FMaHSo067060 for <[e-mail]>; Wed, 15 Apr 2009 15:36:28 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.101] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeZhXwB=[e-mail]> for <[e-mail]>; Wed, 15 Apr 2009 23:36:16 +0100
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt 
Date: Wed, 15 Apr 2009 15:36:13 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a simple refresh.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FKkFo5059784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 13:46:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FKkFlR059781; Wed, 15 Apr 2009 13:46:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FKkFiQ059769 for <[e-mail]>; Wed, 15 Apr 2009 13:46:15 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 0F1163A6F4C; Wed, 15 Apr 2009 13:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-sasl-4422bis-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 15 Apr 2009 13:45:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov, K. Zeilenga
	Filename	: draft-ietf-sasl-4422bis-01.txt
	Pages		: 32
	Date		: 2009-4-14
	
The Simple Authentication and Security Layer (SASL) is a framework
   for providing authentication and data security services in
   connection-oriented protocols via replaceable mechanisms.  It
   provides a structured interface between protocols and mechanisms.
   The resulting framework allows new protocols to reuse existing
   mechanisms and allows old protocols to make use of new mechanisms.
   The framework also provides a protocol for securing subsequent
   protocol exchanges within a data security layer.

   This document describes how a SASL mechanism is structured, describes
   how protocols include support for SASL, and defines the protocol for
   carrying a data security layer over a connection.  In addition, this
   document defines one SASL mechanism, the EXTERNAL mechanism.

   This document obsoletes RFC 4422 [[when approved]].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-4422bis-01.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-4422bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FHVtA4043982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 10:31:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FHVteW043981; Wed, 15 Apr 2009 10:31:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FHVicm043972 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 15 Apr 2009 10:31:54 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3FHVhlr019254 for <[e-mail]>; Wed, 15 Apr 2009 17:31:43 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 n3FHVh0B057081 for <[e-mail]>; Wed, 15 Apr 2009 11:31:43 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3FHMI6Z011688 for <[e-mail]>; Wed, 15 Apr 2009 12:22:18 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FHMIKl011687 for [e-mail]; Wed, 15 Apr 2009 12:22:18 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 15 Apr 2009 12:22:18 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've updated the I-D:

http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-02.txt

I've removed the words "abstract API".  I believe the I-D is entirely
prescriptive of how applications interact with SASL mechanisms.  The I-D
is NOT prescriptive of any SASL mechanism details, but it does impose a
pair of requirements on SASL mechanisms in a way that does not dictate
mechanism design.  The new version is entirely in keeping with RFC4422,
IMO.

The new text should allow for mechanisms like YAP that require the use
of unique channel binding types, as it now requires that the app provide
the channel bindings for all available channel binding types.


Incidentally, I believe YAP can be seen as a variant of SCRAM that
optimizes away one round trip, using the channel binding as the client
and server nonce, and caching the salt and iteration count on the client
side.  Whereas SCRAM looks like:

      C: p,a=cnewman,n=Chris Newman,r=ClientNonce
      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
      C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4

YAP as a variant of SCRAM would look like:

      C: p,a=cnewman,n=Chris Newman,r=<channel-binding-type:data>,
         s=PxR/wv+epq,i=128,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4

or, if the client's idea of the user's salt and itteration count is
wrong:

      C: p,a=cnewman,n=Chris Newman,r=<channel-binding-type:data>,
         s=PxR/wv+epq,i=128,p=WxPv/siO5l+qxN4
      S: s=PxR/wv+epq,i=128
      C: p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4

(No, I did not compute actual HMACs and base64 encodings of them.)

If you respond to the YAP-as-variant-of-SCRAM part of this message then
please change the Subject header line.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FHVFJd043929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 10:31:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FHVFKO043927; Wed, 15 Apr 2009 10:31:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FHVE0m043921 for <[e-mail]>; Wed, 15 Apr 2009 10:31:14 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id E839D3A6E7A; Wed, 15 Apr 2009 10:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 15 Apr 2009 10:30:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-02.txt
	Pages           : 9
	Date            : 2009-04-15

This document specifies the semantics of channel binding for the
Simple Authentication and Security Layers (SASL) framework,
mechanisms and applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-02.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-channel-bindings-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FHGFvJ042845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 10:16:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FHGFDb042844; Wed, 15 Apr 2009 10:16:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FHGEee042837 for <[e-mail]>; Wed, 15 Apr 2009 10:16:15 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id D77BC3A6BBE; Wed, 15 Apr 2009 10:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 15 Apr 2009 10:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-01.txt
	Pages           : 9
	Date            : 2009-04-15

This document specifies the semantics of channel binding for the
Simple Authentication and Security Layers (SASL) framework,
mechanisms and applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-01.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-channel-bindings-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FGVmed039252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 09:31:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FGVmQn039251; Wed, 15 Apr 2009 09:31:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FGVa2f039241 for <[e-mail]>; Wed, 15 Apr 2009 09:31:47 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.101] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeYL5gB=[e-mail]>; Wed, 15 Apr 2009 17:31:35 +0100
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Wed, 15 Apr 2009 09:31:32 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 15, 2009, at 8:28 AM, Nicolas Williams wrote:

>
> On Wed, Apr 15, 2009 at 01:19:36PM +0200, Simon Josefsson wrote:
>> Having read the replies, and agreeing fully with Jeff's notion that  
>> the
>> IETF should not have a monopoly of EXTERNAL-* mechanisms, let me  
>> suggest
>> that we use a First-Come-First-Serve model.  [...]
>>
>> I don't care strongly which approach to use.  So I would be fine with
>> any of (in preference order) FCFS, specification required, or expert
>> review.  I do feel strongly that it should not be difficult to get a
>> IANA allocation.  We have plenty of bad experience with protocols  
>> that
>> has too rigid protocol number allocation policies.
>
> I don't care strongly either.  FCFS w/ specification required (but not
> expert review, not standards action) seems like the best approach.
>
> EXTERNAL is not exactly tricky, after all, so why demand, say, expert
> review?

Expert review is useful when it not feasible to let IANA to  
mechanically hand out assignments.

Expert review need not be heavy nor result in a denial.

     Additional names may be registered under Expert Review or IESG  
Approval [RFC5226].

     Registration of mechanisms detailed in IETF documents require  
IESG Approval.  The IESG Approval route
     is also open to others, such as those whose requests were denied  
under the Expert Review route.

     The Designated Expert will review only the appropriateness of the  
requested name for the requested purpose.
     No specification is required.  Where a specification is provided,  
the particulars of the specification are
     not to be considered by the Designated Expert.  Where the  
Designated Expert finds the requested name to be inappropriate,
     the Designated Expert should recommend a more appropriate name  
within the family and, if acceptable by the requestor, this
     name will be registered without any further review.  In hopefully  
rare cases where the Designated Expert finds the request
     wholly unacceptable (for instance, when the stated purpose has  
nothing to do with the purpose of the family), the
     Designated Expert may deny the request.  Actions of the Expert  
are appealable [RFC2026].

That is, the Reviewer should avoid reviewing the particulars of the  
mechanism and simply focus on whether the requested name is sensible  
for the requested purpose.  IANA prefers not to make such judgements,  
hence the need for Expert Review.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FFbiBE034194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 08:37:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FFbipT034192; Wed, 15 Apr 2009 08:37:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FFbXGe034173 for <[e-mail]>; Wed, 15 Apr 2009 08:37:43 -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 n3FFbWKI026165 for <[e-mail]>; Wed, 15 Apr 2009 15:37:33 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3FFbWTo029016 for <[e-mail]>; Wed, 15 Apr 2009 09:37:32 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3FFS5A6011444; Wed, 15 Apr 2009 10:28:05 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3FFS42W011443; Wed, 15 Apr 2009 10:28:04 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 15 Apr 2009 10:28:04 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-02
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 15, 2009 at 01:19:36PM +0200, Simon Josefsson wrote:
> Having read the replies, and agreeing fully with Jeff's notion that the
> IETF should not have a monopoly of EXTERNAL-* mechanisms, let me suggest
> that we use a First-Come-First-Serve model.  [...]
> 
> I don't care strongly which approach to use.  So I would be fine with
> any of (in preference order) FCFS, specification required, or expert
> review.  I do feel strongly that it should not be difficult to get a
> IANA allocation.  We have plenty of bad experience with protocols that
> has too rigid protocol number allocation policies.

I don't care strongly either.  FCFS w/ specification required (but not
expert review, not standards action) seems like the best approach.

EXTERNAL is not exactly tricky, after all, so why demand, say, expert
review?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FBJrbG011075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 04:19:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FBJrVP011074; Wed, 15 Apr 2009 04:19:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FBJdIr011053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 15 Apr 2009 04:19:52 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lu39V-0007HT-Si; Wed, 15 Apr 2009 13:19:38 +0200
X-Hashcash: 1:22:090415:[e-mail]::8qgHjv0iRULD1uEN:04Ys
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-02
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090415:[e-mail]::y+qsyRDRXWokz3Wv:FKXj
Date: Wed, 15 Apr 2009 13:19:36 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 14 Apr 2009 12:48:05 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> Simon,
>
> Overall, this I-D mets my needs.  Thanks!

Great.

> One issue the I-D needs to discuss is how to establish additional
> EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC
> or EXTERNAL-IPC.  How are names of family members ensured to be
> unique?  etc.

Having read the replies, and agreeing fully with Jeff's notion that the
IETF should not have a monopoly of EXTERNAL-* mechanisms, let me suggest
that we use a First-Come-First-Serve model.  It is important to ensure
uniqueness of mechanism names, and in my experience both expert review
and specification required models can delay or defer people to request a
mechanism name.  That is bad.  Further, I see strong benefit in the
expert reviewer or specification required model over FCFS.  Thoughts?

I don't care strongly which approach to use.  So I would be fine with
any of (in preference order) FCFS, specification required, or expert
review.  I do feel strongly that it should not be difficult to get a
IANA allocation.  We have plenty of bad experience with protocols that
has too rigid protocol number allocation policies.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ENOh0u063971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 16:24:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3ENOhab063970; Tue, 14 Apr 2009 16:24:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ENOf9F063962 for <[e-mail]>; Tue, 14 Apr 2009 16:24:41 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeUbNgB=[e-mail]>; Wed, 15 Apr 2009 00:24:39 +0100
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 16:24:35 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 14, 2009, at 2:27 PM, Jeffrey Hutzelman wrote:

>
> --On Tuesday, April 14, 2009 01:52:52 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>>
>> On Apr 14, 2009, at 12:37 PM, Jeffrey Hutzelman wrote:
>>
>>>
>>> --On Tuesday, April 14, 2009 12:06:38 PM -0700 Kurt Zeilenga
>>> <[e-mail]
>>> > wrote:
>>>
>>>>
>>>> RFC 4422 purposed avoided detailing APIs.
>>>
>>> We're talking about abstractions, not API's.
>>
>>
>> I argue that the I-D does detail interfaces (beyond what RFC 4422  
>> says).
>> It specifically discusses what and when channel binding information  
>> and
>> mechanism information is to be passed between components of an
>> implementation.
>>
>>     In order to use SASL [RFC4422] with channel binding the client  
>> and
>> server applications MUST provide a channel binding type and channel
>> binding data to the selected SASL mechanism before the first  
>> mechanism's
>> authentication message is produced (client side) or consumed (server
>> side).
>> This is unnecessarily prescriptive.
>
> No, it's not, though you may be reading too much into it.  A SASL  
> protocol must be prepared to make channel binding information  
> available to the mechanism by the first time the mechanism produces  
> or consumes a message, because some mechanisms will be unable to  
> process channel bindings unless the data is available at that time.   
> We're not telling you how your implementation API has to work; we're  
> telling you not to design a protocol that expects not to provide  
> channel binding data to the mechanism until after some mechanism  
> tokens have been exchanged, because such a protocol will not work.

Then you should word this as a requirement upon application protocol  
specifications instead of requirement upon implementors.

>
>
>
>> Yes, but it's descriptive in nature, not prescriptive.  I find the
>> language in the I-D far too prescriptive.
>
> No, it's prescriptive.  It doesn't describe how the existing  
> mechanisms and protocols happen to be; it describes things that must  
> be true of all mechanisms and protocols and they way they interact.   
> Unless you're using the words "descriptive" and "prescriptive" in a  
> with which I'm not familiar.
>
>
>> Of course.   I've tried to avoid use of the term API.
>>
>>> What draft-ietf-sasl-channel-bindings does is extend the abstract
>>> interface defined by RFC4422 to encompass handling of channel
>>> bindings.
>>
>> I argue that
>> 	1) no change to RFC 4422 is required to "handle channel bindings"
>> 	(the I-D implies changes are required)
>>
>> 	2) while adding some recommendations and considerations might be
>> appropriate at this time,
>>         I generally think it premature to mandate particulars of  
>> channel
>> binding in the SASL specification.
>>
>>> It does so by saying that mechanisms may support channel binding and
>>> protocols may provide CB data to the mechanism.
>>
>> The I-D and its proponents appear to be arguing that changes to RFC  
>> 4422
>> are required for SCRAM, YAP and other mechanisms to be successfully
>> implemented and deployed, and uses this 'requirement' to justify  
>> nearly a
>> dozen mandates.
>>
>> I argue that the premise that changes to RFC 4422 are required is
>> incorrect.  No change to RFC 4422 is required for such mechanisms  
>> to be
>> successfully implemented and deployed.
>
> A change to the abstraction is required in order to allow  
> specifying, implementing, and deploying support for channel bindings  
> in SCRAM, YAP, GS2, and other mechanisms without breaking the  
> abstraction and requiring that protocols understand the details of  
> specific mechanisms, now and forevermore.

I think the change you refer to is an implementation detail.

RFC 4422 said that while it possible to abstract away differences  
between a set of mechanisms, such abstractions will have to adapt in  
order to handle new mechanisms with yet more differences.

This is the nature of SASL as specified.

> Again, I find that abstraction _essential_.

I find it desirable.

>
> It is _intolerable_ to me that protocols should have to have  
> mechanism-specific knowledge about each mechanism.

Protocol specifications or protocol implementations?  Or both.

RFC 4422 is clear that it offers the former but not the latter.

> I find such a requirement contrary to the fundamental nature of SASL.
>
> There is no getting around this.

There is no getting around the issue that in order to implement a  
different mechanism that one might have to change aspects of the  
framework and protocol implementation.  This has always been true, and  
is part of the fundamental nature of SASL approach to authentication  
frameworks.

>
>
> Of course, one could change the abstraction without bothering to  
> document it.  That's essentially what you've done if SCRAM, YAP, and  
> GS2 all handle channel bindings in a similar way and protocols and  
> protocol implementations start depending on it, but we _don't_  
> update RFC4422.

Consider introduction of realms [RFC 2831].   The only thing we  
changed from RFC 2222 to RFC 4422 was to note that some mechanisms  
have a realm concept (the word "realm" did appear in RFC 2222, but  
only within the specification of the KERBEROS_V4 mechanism).  Despite  
the introduction having numerous impacts of this upon the abstractions  
implementors had designed/are designing to hide the differences  
between mechanisms, we didn't specify anything about realms.

> Then what happens is a couple of years from now, someone writes a  
> protocol or mechanism that violates the unwritten assumptions, and  
> we have a mess on our hands.

Well, I might suggest a word of caution be added to RFC 4422 text:

It is possible to design and implement this framework in ways that do  
abstract away particulars of similar mechanisms. Such a framework  
implementation, as well as mechanisms implementations, could be  
designed not only to be shared by multiple implementations of a  
particular protocol but to be shared by implementations of multiple  
protocols.
that notes that expanding an existing implementation to handle  
mechanisms and/or protocols dissimilar from those previously support  
might require substantial reworking of the implementation.

However, I think RFC 4422 is already quite clear that it does not  
generally hide the particulars of mechanisms from protocol  
implementations nor the differences of protocols from mechanism  
implementations.

>
>
> Since the purpose of the IETF is, in large part, to document  
> protocols bits _and semantics_, I feel we should do our job and  
> document the changes we are making to the SASL abstraction.   
> Otherwise, why are we here?

While we're introducing mechanisms which are notably dissimilar to  
existing mechanisms, and that introduction will impact abstractions  
implementors have designed and implemented, I don't believe the  
introduction of these mechanisms changes the SASL conceptional model  
or otherwise necessities a change in RFC 4422.

I note that what I object to is the premise that adding the text is  
required.  I argue that adding text about channel binding is merely  
desirable.  The difference in premise one starts with significant  
impacts the text.  In particular, where this I-D contains nearly a  
dozen mandates, the text that I would likely offer would likely  
contain zero mandates and a number of weak recommendations (similar to  
the weak recommendations we have on various other mechanism data  
requirements).


>
>
>
>> So before we argue about individual mandates, I'd like the premise  
>> of the
>> I-D to be restated.
>
> The premise of the I-D is, "in order to say 'SCRAM does XXX with the  
> channel bindings data provided by the protocol', we must first say  
> that the protocol can provide channel bindings data to mechanisms."
>
> Do you disagree with that assertion?

First, I assume by "protocol" your refer to a component of an  
implementation that implements a particular application level  
protocol, such as XMPP.

I would agree that a component of an implementation that implements  
that SCRAM mechanism needs to provided with the inputs the SCRAM  
mechanism requires.

> Do you believe it is OK to simply _assume_ that SASL protocols can  
> provide channel bindings data to mechanisms, without saying what CB  
> data is or what it's for or what it means?

I think SCRAM specification needs to be clear as to what the SCRAM  
mechanism input requirements are.

I see no specification barrier to implementation of SCRAM.

I note again SCRAM has been implemented.  I have not heard any SCRAM  
implementor stating the specifications of SCRAM nor RFC 4422 where  
incomplete or otherwise insufficient to allow for independent  
interoperability implementation of the mechanism.

> Do you believe it is OK to simply _assume_ that SASL protocols will  
> always be designed such that CB data is available to mechanisms in  
> time to use it, without actually making this a requirement of SASL  
> protocol designs?

Today implementations will try mechanisms for which they do not have  
all the required data inputs for.  I suspect this problem will  
continue.  I don't think this issue is unique to any particular data  
input requirement.


> Do you believe it is OK for SASL protocols to simply _assume_ that  
> if they provide channel binding data to the mechanism and the  
> authentication succeeds, then it is safe to rely on the security  
> properties of the lower layer channel and that there is no MitM?

I think implementors need to well understand the implementation- 
specific interfaces they use and be very careful of what assumptions  
they make.

> Or do we need to require mechanisms that provide support for channel  
> bindings to actually guarantee this?

I think mechanism specifications should be clear as to what security  
properties are provided under various circumstances.

>
>
>> I might agree to such so long as we don't mandate the CB data be  
>> RFC 5056
>> CB data.  Now maybe I read too much in the draft, but given that my
>> suggested SHOULD was not well received by Nico, I assume I read the  
>> I-D
>> correctly.
>
> I believe it is appropriate to specify that when we're talking about  
> "channel bindings", we mean the concept described by RFC5056.  I  
> believe it is critically important to specify that we're not talking  
> about what EAP means when it talks about "channel bindings".
>
> I don't believe it's necessarily important to require that channel  
> binding tokens have a particular format, or that they use the  
> binding types listed in the registry which RFC5056 creates.  I also  
> don't believe that the present I-D requires that, or that RFC5056  
> requires that.
>
>
>
>>>> No, we've (basically) decided that use of channel binding in SCRAM
>>>> and GS
>>>> should be negotiable.   We haven't made any decision that all  
>>>> futures
>>>> that support channel bindings must do so in a manner which is
>>>> negotiable.
>>>
>>>
>>>>> That means we MUST specify what channel
>>>>> binding means in the context of SASL.
>>>>
>>>> In the context of SCRAM certainly.  In general, no.
>>>
>>> No, if we do it at all, we must do it at the SASL layer.  Attempting
>>> to do it only at the SCRAM layer violates the abstraction, by
>>> requiring every protocol to have mechanism-specific knowledge.
>>
>> RFC 4422 doesn't hide particulars of mechanism implementations from
>> particulars of framework implementations from particulars of  
>> application
>> protocol mechanisms.
>>
>> The RFC 4422 abstraction only allows for protocols and mechanisms  
>> to be
>> specified independently.
>
> Correct.  But note that I didn't say "... requiring every protocol  
> implementation to have mechanism-implementation-specific  
> knowledge".  I meant what I said -- if we only specify what channel  
> bindings mean for SCRAM, and for YAP, and for GS2, then each  
> protocol specification must specify how to handle channel bindings  
> for SCRAM, and for YAP, and for GS2, and each protocol specification  
> must be updated every time a new mechanism comes along that supports  
> channel binding.  That is intolerable.
>
> And frankly, the abstraction _does_ allow for protocols and  
> mechanisms to be implemented independently, as evidenced by the  
> existence of multiple SASL framework libraries which do exactly  
> this.  I do _not_ want to see this capability go away because  
> someone decided it would be OK to ignore the abstraction and start  
> requiring every protocol to have specific knowledge of every  
> mechanism.
>
>
>> I guess we disagree on the point of SASL is.
>
> Maybe.  My interpretation goes back to the pre-SASL days when the  
> Cyrus IMAP server included an abstraction for supporting multiple  
> authentication methods, specifically so that the rest of the  
> software and the IMAP protocol would not need to know the  
> particulars of any given mechanism.
>
>> I argue it is premature to view our channel binding solution to be  
>> the
>> end-all solution to channel binding.
>
> You keep saying this.  But see, we are specifying how to do channel  
> binding in SASL.  I've explained in several ways why it is necessary  
> to do this at the SASL level, and not for each separate  
> (protocol,mechanism) tuple, and the argument boils down to this: we  
> do not have the infinite time it would take to do the latter.
>
> It is entirely possible we will need to change the abstraction again  
> later, in response to new information.  But despite the fact that we  
> are only now getting around to nailing down the details for SASL,  
> channel bindings are not a new concept; the IETF has been working on  
> this for several years, and RFC5056 is a standards-track document  
> which represents the consensus of the IETF on how to handle channel  
> bindings.
>
>> Oh please.  Nothing I suggest hinders your ability to abstract away  
>> the
>> particulars of mechanisms and protocols.  Folks have been doing  
>> this for
>> ages.
>
> You suggest allowing the abstraction to be different for every  
> mechanism. That precludes abstracting away the differences between  
> mechanisms.

In one extreme, yes, every mechanism differs in every regard.  But in  
the other extreme, ever mechanism is the same in very regard.

I think mechanisms ought to be similar where appropriate and different  
where appropriate, where what's appropriate is largely left to the  
designer of the mechanism.

If a designer doesn't design well, oh well.

>
>
>>>> Your I-D gets into details which RFC 4422 left to implementors.   
>>>> For
>>>> instance, it mandates what and when and how channel binding data is
>>>> passed between two components of implementation.
>>>
>>> No, it mandates what and when and how channel binding data is passed
>>> between abstract components in a (implied) block diagram, which may
>>> or may not bear any resemblance to an actual implementation.  In the
>>> same way that RFC4422 mandates what and when and how mechanism
>>> tokens or security layer buffers are passed between the same
>>> abstract components.
>>
>> I guess we'll just have to agree to disagree.
>
> No, I don't think we can do that.  We need to reach a rough  
> consensus in order to move forward.  I do not believe it is  
> appropriate to move forward with documents such as SCRAM, GS2, and  
> YAP, without updating RFC4422 to reflect the changes they make to  
> the SASL abstraction.

What text in RFC 4422 need to change in order for a developer to  
implement YAP as currently specified?

> You appear to believe it is not appropriate to update RFC4422 to  
> reflect the changes we are making to the abstraction.

I believe that the introduction of mechanisms which differ  
significantly from existing mechanisms does not necessitate a change  
to RFC 4422.

It is the nature of SASL that such introductions will likely have an  
impact upon implementation-specific abstractions to hide the details  
of mechanisms from protocol implementations.

> These positions are in direct conflict, which we need to resolve.
>
> -- Jeff
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ELS5Kf057676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 14:28:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3ELS5Vs057675; Tue, 14 Apr 2009 14:28:05 -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.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ELS4uO057666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 14 Apr 2009 14:28:04 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-33-211.pools.spcsdns.net (68-247-33-211.pools.spcsdns.net [68.247.33.211]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3ELRwcr005454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 17:28:00 -0400 (EDT)
Date: Tue, 14 Apr 2009 17:27:58 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
cc: Nicolas Williams <[e-mail]>, [e-mail], [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, April 14, 2009 01:52:52 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> On Apr 14, 2009, at 12:37 PM, Jeffrey Hutzelman wrote:
>
>>
>> --On Tuesday, April 14, 2009 12:06:38 PM -0700 Kurt Zeilenga
>> <[e-mail]
>> > wrote:
>>
>>>
>>> RFC 4422 purposed avoided detailing APIs.
>>
>> We're talking about abstractions, not API's.
>
>
> I argue that the I-D does detail interfaces (beyond what RFC 4422 says).
> It specifically discusses what and when channel binding information and
> mechanism information is to be passed between components of an
> implementation.
>
>      In order to use SASL [RFC4422] with channel binding the client and
> server applications MUST provide a channel binding type and channel
> binding data to the selected SASL mechanism before the first mechanism's
> authentication message is produced (client side) or consumed (server
> side).
> This is unnecessarily prescriptive.

No, it's not, though you may be reading too much into it.  A SASL protocol 
must be prepared to make channel binding information available to the 
mechanism by the first time the mechanism produces or consumes a message, 
because some mechanisms will be unable to process channel bindings unless 
the data is available at that time.  We're not telling you how your 
implementation API has to work; we're telling you not to design a protocol 
that expects not to provide channel binding data to the mechanism until 
after some mechanism tokens have been exchanged, because such a protocol 
will not work.


> Yes, but it's descriptive in nature, not prescriptive.  I find the
> language in the I-D far too prescriptive.

No, it's prescriptive.  It doesn't describe how the existing mechanisms and 
protocols happen to be; it describes things that must be true of all 
mechanisms and protocols and they way they interact.  Unless you're using 
the words "descriptive" and "prescriptive" in a with which I'm not familiar.


> Of course.   I've tried to avoid use of the term API.
>
>> What draft-ietf-sasl-channel-bindings does is extend the abstract
>> interface defined by RFC4422 to encompass handling of channel
>> bindings.
>
> I argue that
> 	1) no change to RFC 4422 is required to "handle channel bindings"
> 	(the I-D implies changes are required)
>
> 	2) while adding some recommendations and considerations might be
> appropriate at this time,
>          I generally think it premature to mandate particulars of channel
> binding in the SASL specification.
>
>> It does so by saying that mechanisms may support channel binding and
>> protocols may provide CB data to the mechanism.
>
> The I-D and its proponents appear to be arguing that changes to RFC 4422
> are required for SCRAM, YAP and other mechanisms to be successfully
> implemented and deployed, and uses this 'requirement' to justify nearly a
> dozen mandates.
>
> I argue that the premise that changes to RFC 4422 are required is
> incorrect.  No change to RFC 4422 is required for such mechanisms to be
> successfully implemented and deployed.

A change to the abstraction is required in order to allow specifying, 
implementing, and deploying support for channel bindings in SCRAM, YAP, 
GS2, and other mechanisms without breaking the abstraction and requiring 
that protocols understand the details of specific mechanisms, now and 
forevermore.


Again, I find that abstraction _essential_.
It is _intolerable_ to me that protocols should have to have 
mechanism-specific knowledge about each mechanism.  I find such a 
requirement contrary to the fundamental nature of SASL.


There is no getting around this.

Of course, one could change the abstraction without bothering to document 
it.  That's essentially what you've done if SCRAM, YAP, and GS2 all handle 
channel bindings in a similar way and protocols and protocol 
implementations start depending on it, but we _don't_ update RFC4422.  Then 
what happens is a couple of years from now, someone writes a protocol or 
mechanism that violates the unwritten assumptions, and we have a mess on 
our hands.

Since the purpose of the IETF is, in large part, to document protocols bits 
_and semantics_, I feel we should do our job and document the changes we 
are making to the SASL abstraction.  Otherwise, why are we here?


> So before we argue about individual mandates, I'd like the premise of the
> I-D to be restated.

The premise of the I-D is, "in order to say 'SCRAM does XXX with the 
channel bindings data provided by the protocol', we must first say that the 
protocol can provide channel bindings data to mechanisms."

Do you disagree with that assertion?

Do you believe it is OK to simply _assume_ that SASL protocols can provide 
channel bindings data to mechanisms, without saying what CB data is or what 
it's for or what it means?

Do you believe it is OK to simply _assume_ that SASL protocols will always 
be designed such that CB data is available to mechanisms in time to use it, 
without actually making this a requirement of SASL protocol designs?

Do you believe it is OK for SASL protocols to simply _assume_ that if they 
provide channel binding data to the mechanism and the authentication 
succeeds, then it is safe to rely on the security properties of the lower 
layer channel and that there is no MitM?  Or do we need to require 
mechanisms that provide support for channel bindings to actually guarantee 
this?

> I might agree to such so long as we don't mandate the CB data be RFC 5056
> CB data.  Now maybe I read too much in the draft, but given that my
> suggested SHOULD was not well received by Nico, I assume I read the I-D
> correctly.

I believe it is appropriate to specify that when we're talking about 
"channel bindings", we mean the concept described by RFC5056.  I believe it 
is critically important to specify that we're not talking about what EAP 
means when it talks about "channel bindings".

I don't believe it's necessarily important to require that channel binding 
tokens have a particular format, or that they use the binding types listed 
in the registry which RFC5056 creates.  I also don't believe that the 
present I-D requires that, or that RFC5056 requires that.



>>> No, we've (basically) decided that use of channel binding in SCRAM
>>> and GS
>>> should be negotiable.   We haven't made any decision that all futures
>>> that support channel bindings must do so in a manner which is
>>> negotiable.
>>
>>
>>>> That means we MUST specify what channel
>>>> binding means in the context of SASL.
>>>
>>> In the context of SCRAM certainly.  In general, no.
>>
>> No, if we do it at all, we must do it at the SASL layer.  Attempting
>> to do it only at the SCRAM layer violates the abstraction, by
>> requiring every protocol to have mechanism-specific knowledge.
>
> RFC 4422 doesn't hide particulars of mechanism implementations from
> particulars of framework implementations from particulars of application
> protocol mechanisms.
>
> The RFC 4422 abstraction only allows for protocols and mechanisms to be
> specified independently.

Correct.  But note that I didn't say "... requiring every protocol 
implementation to have mechanism-implementation-specific knowledge".  I 
meant what I said -- if we only specify what channel bindings mean for 
SCRAM, and for YAP, and for GS2, then each protocol specification must 
specify how to handle channel bindings for SCRAM, and for YAP, and for GS2, 
and each protocol specification must be updated every time a new mechanism 
comes along that supports channel binding.  That is intolerable.

And frankly, the abstraction _does_ allow for protocols and mechanisms to 
be implemented independently, as evidenced by the existence of multiple 
SASL framework libraries which do exactly this.  I do _not_ want to see 
this capability go away because someone decided it would be OK to ignore 
the abstraction and start requiring every protocol to have specific 
knowledge of every mechanism.


> I guess we disagree on the point of SASL is.

Maybe.  My interpretation goes back to the pre-SASL days when the Cyrus 
IMAP server included an abstraction for supporting multiple authentication 
methods, specifically so that the rest of the software and the IMAP 
protocol would not need to know the particulars of any given mechanism.

> I argue it is premature to view our channel binding solution to be the
> end-all solution to channel binding.

You keep saying this.  But see, we are specifying how to do channel binding 
in SASL.  I've explained in several ways why it is necessary to do this at 
the SASL level, and not for each separate (protocol,mechanism) tuple, and 
the argument boils down to this: we do not have the infinite time it would 
take to do the latter.

It is entirely possible we will need to change the abstraction again later, 
in response to new information.  But despite the fact that we are only now 
getting around to nailing down the details for SASL, channel bindings are 
not a new concept; the IETF has been working on this for several years, and 
RFC5056 is a standards-track document which represents the consensus of the 
IETF on how to handle channel bindings.

> Oh please.  Nothing I suggest hinders your ability to abstract away the
> particulars of mechanisms and protocols.  Folks have been doing this for
> ages.

You suggest allowing the abstraction to be different for every mechanism. 
That precludes abstracting away the differences between mechanisms.

>>> Your I-D gets into details which RFC 4422 left to implementors.  For
>>> instance, it mandates what and when and how channel binding data is
>>> passed between two components of implementation.
>>
>> No, it mandates what and when and how channel binding data is passed
>> between abstract components in a (implied) block diagram, which may
>> or may not bear any resemblance to an actual implementation.  In the
>> same way that RFC4422 mandates what and when and how mechanism
>> tokens or security layer buffers are passed between the same
>> abstract components.
>
> I guess we'll just have to agree to disagree.

No, I don't think we can do that.  We need to reach a rough consensus in 
order to move forward.  I do not believe it is appropriate to move forward 
with documents such as SCRAM, GS2, and YAP, without updating RFC4422 to 
reflect the changes they make to the SASL abstraction.  You appear to 
believe it is not appropriate to update RFC4422 to reflect the changes we 
are making to the abstraction.  These positions are in direct conflict, 
which we need to resolve.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ELKEKv057336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 14:20:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3ELKEvm057335; Tue, 14 Apr 2009 14:20:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ELKCOf057327 for <[e-mail]>; Tue, 14 Apr 2009 14:20:13 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeT-CgB=[e-mail]>; Tue, 14 Apr 2009 22:20:11 +0100
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 14:20:05 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 14, 2009, at 12:34 PM, Nicolas Williams wrote:
> Let's short-circuit this discussion as we're going around in circles.

Okay.

> You are asserting that YAP by design can only use unique channel  
> binding
> types and, indeed, MUST use channel binding with unique channel  
> binding
> types.  And you want this to fit in the SASL channel binding concept,
> whether that concept exists as a specification or not.

I note that I only used YAP in this thread to illustrate that what we  
thing today (or, I guess yesterday) was adequate for all future  
mechanisms is not necessarily adequate.

The fact that you can adjust your proposal to account for YAP says  
nothing about your current or modified proposal being about to deal  
well with what some future mechanism designer might wish to do in  
their mechanism.

> Fine.  Propose some text, possibly using the alternative approach  
> that I
> mentioned: require that applications provide *all* available channel
> bindings for all available types for the channel being bound to.  Then
> the mechanism can select which one to use.

I already proposed an alternative approach but you seemed to have  
ignored it.

I'll repeat it here:

Now, what I would suggest is to start with a slight different premise:  
It is desirable for mechanisms supporting channeling binding do so in  
similar manner.       And then to make some RECOMMENDations along this  
line. Such as adding to Section 5 of RFC 4422,

  SASL mechanisms SHOULD reuse existing channel bindings forms, as  
well as associated syntaxes and semantics, such as detailed in  
[RFC5056].

and then work outward from there (adding some discussion of channel  
binding security considerations, etc.).

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EL8Utr056656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 14:08:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EL8UB4056655; Tue, 14 Apr 2009 14:08:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EL8Tiw056649 for <[e-mail]>; Tue, 14 Apr 2009 14:08:29 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeT7SgB=[e-mail]>; Tue, 14 Apr 2009 22:08:27 +0100
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Tue, 14 Apr 2009 14:08:24 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 14, 2009, at 12:54 PM, Jeffrey Hutzelman wrote:

>
> --On Tuesday, April 14, 2009 12:48:05 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>>
>> Simon,
>>
>> Overall, this I-D mets my needs.  Thanks!
>>
>> One issue the I-D needs to discuss is how to establish additional
>> EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL- 
>> IPSEC or
>> EXTERNAL-IPC.  How are names of family members ensured to be  
>> unique?  etc.
>>
>> I suggest that EXTERNAL-* family members be registered in the SASL
>> mechanism name table under an Expert Review Required policy.  I  
>> rather
>> not use "Specification Required" as that overly burdensome, and I  
>> don't
>> see any particular reason for the IETF to have a monopoly on the  
>> design
>> of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd likely  
>> do so
>> outside of the IETF.)
>
> Uh, generally Specification Required is _less_ restrictive than  
> Expert Review, as it only requires that you provide a specification  
> rather than requiring approval from someone.

I note that RFC 5226 says "Specification Required also implies use of  
a Designated Expert".  Designated Expert is an alias for Expert Review.

Anyways, though a document can place all kinds of requirements upon  
what an "Expert Review" might cover, I was thinking of a review  
limited to the appropriateness of the request.  That is, no  
requirement (but no preclusion) that the Expert review anything  
outside the registration request.

I would be fine with Specification Required.  The difference doesn't  
matter much (to me).

> Meeting the requirement means providing some form of specification;  
> it does not require an RFC, let alone IETF approval.
>
>
> That said, I agree with the approach, and with the notion that the  
> IETF needn't have a monopoly on EXTERNAL-* mechanisms.
>
> -- Jeff
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EKr9GO055882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 13:53:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EKr9W4055881; Tue, 14 Apr 2009 13:53:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EKqv90055864 for <[e-mail]>; Tue, 14 Apr 2009 13:53:08 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeT3pwB=[e-mail]>; Tue, 14 Apr 2009 21:52:55 +0100
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 13:52:52 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 14, 2009, at 12:37 PM, Jeffrey Hutzelman wrote:

>
> --On Tuesday, April 14, 2009 12:06:38 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>>
>> RFC 4422 purposed avoided detailing APIs.
>
> We're talking about abstractions, not API's.


I argue that the I-D does detail interfaces (beyond what RFC 4422  
says).  It specifically discusses what and when channel binding  
information and mechanism information is to be passed between  
components of an implementation.

     In order to use SASL [RFC4422] with channel binding the client  
and server applications MUST provide a channel binding type and  
channel binding data to the selected SASL mechanism before the first  
mechanism's authentication message is produced (client side) or  
consumed (server side).
This is unnecessarily prescriptive.
>
>
>> It merely says that generally
>> possible to abstract interfaces between application protocols and a
>> framework and between a framework and a mechanisms.  It leaves the
>> particulars of what boundaries to draw between components of an
>> implementation to the implementation, as well as the particulars of  
>> what
>> is passed over those boundaries, and when, etc.
>
> Not really.  It _claims_ to do that, but then it goes on to describe  
> what is expected of protocols and mechanisms.  It _does_ create an  
> abstraction; if it didn't, it would be useless.

Yes, but it's descriptive in nature, not prescriptive.  I find the  
language in the I-D far too prescriptive.


>
>
> For example, we know that mechanisms produce tokens which the  
> protocol is expected to transport back and forth, but whose format  
> and semantics are known only to the mechanism.  And, we know that  
> the client and server sides of a mechanism always take turns  
> producing tokens, so that the protocol can transport them via a  
> challenge/response or request/reply sort of exchange.
>
> We know that mechanisms result in either success or failure, but  
> that it is up to the protocol to decide how to convey this from  
> server to client.  In the case of success, mechanisms also produce  
> an authenticated name, whose syntax and semantics are mechanism- 
> specific(*).
>
> We also know that protocols may provide an authorization name, whose  
> syntax and semantics are known only to the protocol, but which the  
> mechanism is responsible for transporting from client to server,  
> possibly (preferably?) in a secure manner.
>
> We know that mechanisms may provide a facility for encryption and/or  
> integrity protection of application data exchange after the  
> authentication process completes.  We know that when such a layer is  
> in use, it works by the protocol passing definite-length chunks of  
> protocol data ("buffers") to the mechanism, which transforms them  
> into buffers of protected data in a mechanism format.  The protocol  
> is then responsible for transporting the protected buffers and  
> handing them to the mechanism on the far end, which transforms them  
> back into plain protocol data.
>
>
> All of this, and more, we know because RFC4422 specifies these  
> things about the interaction between protocols and mechanisms,  
> without regard to which protocol and which mechanism.  That is an  
> abstract interface.  "Interface" does not always mean "C function  
> call API".

Of course.   I've tried to avoid use of the term API.

> What draft-ietf-sasl-channel-bindings does is extend the abstract  
> interface defined by RFC4422 to encompass handling of channel  
> bindings.

I argue that
	1) no change to RFC 4422 is required to "handle channel bindings"
	(the I-D implies changes are required)

	2) while adding some recommendations and considerations might be  
appropriate at this time,
         I generally think it premature to mandate particulars of  
channel binding in the SASL specification.

> It does so by saying that mechanisms may support channel binding and  
> protocols may provide CB data to the mechanism.

The I-D and its proponents appear to be arguing that changes to RFC  
4422 are required for SCRAM, YAP and other mechanisms to be  
successfully implemented and deployed, and uses this 'requirement' to  
justify nearly a dozen mandates.

I argue that the premise that changes to RFC 4422 are required is  
incorrect.  No change to RFC 4422 is required for such mechanisms to  
be successfully implemented and deployed.

So before we argue about individual mandates, I'd like the premise of  
the I-D to be restated.

> When the mechanism supports CB and the protocol client and server  
> both provide CB data, then authentication succeeds only when the CB  
> data provided on both ends matches.  Like the other items listed  
> above, this behavior is and should be independent of which protocol  
> and which mechanism is used.

I might agree to such so long as we don't mandate the CB data be RFC  
5056 CB data.  Now maybe I read too much in the draft, but given that  
my suggested SHOULD was not well received by Nico, I assume I read the  
I-D correctly.

>> No, we've (basically) decided that use of channel binding in SCRAM  
>> and GS
>> should be negotiable.   We haven't made any decision that all futures
>> that support channel bindings must do so in a manner which is  
>> negotiable.
>
>
>>> That means we MUST specify what channel
>>> binding means in the context of SASL.
>>
>> In the context of SCRAM certainly.  In general, no.
>
> No, if we do it at all, we must do it at the SASL layer.  Attempting  
> to do it only at the SCRAM layer violates the abstraction, by  
> requiring every protocol to have mechanism-specific knowledge.

RFC 4422 doesn't hide particulars of mechanism implementations from  
particulars of framework implementations from particulars of  
application protocol mechanisms.

The RFC 4422 abstraction only allows for protocols and mechanisms to  
be specified independently.

New mechanisms have always tended to introduce new data requirements  
which impact interfaces between components of an implementation.  Such  
an introduction does not break the SASL conceptional model, the impact  
is simply an artifact of the conceptional model.

RFC 4422 says:
    It is possible to design and implement this framework in ways that  
do
    abstract away particulars of similar mechanisms.  Such a framework
    implementation, as well as mechanisms implementations, could be
    designed not only to be shared by multiple implementations of a
    particular protocol but to be shared by implementations of multiple
    protocols.

So, from an RFC 4422 perspective, the differences in channel bindings  
between say it is possible to abstract away particulars of SCRAM and  
YAP channel binding, but that some future mechanism may not fit into  
that abstract.

> That would defeat the point of having SASL in the first place.

I guess we disagree on the point of SASL is.

>
>
>
>>> Did you read the sub-thread we had where Jeff H. commented that the
>>> logic for selecting a channel binding type to use needed to be not
>>> mechanism-specific?
>>
>> Yes, and I agree it need not be mechanism specific.  However, I  
>> disagree
>> that it need be the same in all mechanisms.
>
> Then you missed my point.  The point is _not_ that it does not need  
> to be mechanism-specific.  The point is that it _does_ need to _not_  
> be mechanism-specific.  This is how we avoid writing a hundred new  
> RFC's whenever someone designs a new mechanism.  It's also how sane  
> application protocol implementors avoid having to change their  
> implementations for every new mechanism.

I argue it is premature to view our channel binding solution to be the  
end-all solution to channel binding.

> If you want to implement every combination of protocol x mechanism  
> separately, feel free.  But don't deny me the abstraction that  
> allows me to instead implement each protocol once and each mechanism  
> once,

Oh please.  Nothing I suggest hinders your ability to abstract away  
the particulars of mechanisms and protocols.  Folks have been doing  
this for ages.

> and further to let someone else do most of that work while I reap  
> the benefits simply by changing configuration.
>
> Abstraction is _important_.
> Modularity is _important_.

I assume some implementors will continue to let you do such that.   
Nothing in RFC 4422 ever said implementors of SASL were required to  
abstract away the particulars of mechanisms.  They simply choose to do  
so (and for good reason).

What RFC 4422 did was leave the particulars of such abstractions to  
implementors.  Whether and how a particular implementor chooses to  
abstract away any particular mechanism difference has been, and should  
continue to be, an implementation choice.

> These things provide scalability, and thus feasibility.
> These things make the difference between analysis that is too  
> complicated to be possible, and analysis that is simple enough to do.
>
> Having channel bindings work the same way for every protocol and for  
> every mechanism allows me to analyze how each protocol handles  
> channel bindings and how each mechanism handles channel bindings,  
> instead of having to separately analyze each combination.  This  
> significantly improves my job in promoting the security of my site  
> and of the Internet.
>
>
>> The point here is that any interface between components of an
>> implementation are implementation details, not protocol details.  RFC
>> 4422 specifies protocol, not implementation details.
>
> RFC 4422 specifies almost no protocol.
> It specifies an abstraction.

A very limited abstraction.

>
>
>> Your I-D gets into details which RFC 4422 left to implementors.  For
>> instance, it mandates what and when and how channel binding data is
>> passed between two components of implementation.
>
> No, it mandates what and when and how channel binding data is passed  
> between abstract components in a (implied) block diagram, which may  
> or may not bear any resemblance to an actual implementation.  In the  
> same way that RFC4422 mandates what and when and how mechanism  
> tokens or security layer buffers are passed between the same  
> abstract components.

I guess we'll just have to agree to disagree.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EKPS07054461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 13:25:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EKPS1g054460; Tue, 14 Apr 2009 13:25:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EKPIoP054436 for <[e-mail]>; Tue, 14 Apr 2009 13:25:28 -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 n3EKPHqQ027662 for <[e-mail]>; Tue, 14 Apr 2009 20:25: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 n3EKPH5C003867 for <[e-mail]>; Tue, 14 Apr 2009 14:25:17 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EK8N0U010826; Tue, 14 Apr 2009 15:08:23 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EK8Na6010825; Tue, 14 Apr 2009 15:08:23 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 15:08:23 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-02
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 03:54:02PM -0400, Jeffrey Hutzelman wrote:
> 
> --On Tuesday, April 14, 2009 12:48:05 PM -0700 Kurt Zeilenga 
> <[e-mail]> wrote:
> 
> >
> >Simon,
> >
> >Overall, this I-D mets my needs.  Thanks!
> >
> >One issue the I-D needs to discuss is how to establish additional
> >EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC or
> >EXTERNAL-IPC.  How are names of family members ensured to be unique?  etc.
> >
> >I suggest that EXTERNAL-* family members be registered in the SASL
> >mechanism name table under an Expert Review Required policy.  I rather
> >not use "Specification Required" as that overly burdensome, and I don't
> >see any particular reason for the IETF to have a monopoly on the design
> >of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd likely do so
> >outside of the IETF.)
> 
> Uh, generally Specification Required is _less_ restrictive than Expert 
> Review, as it only requires that you provide a specification rather than 
> requiring approval from someone.  Meeting the requirement means providing 
> some form of specification; it does not require an RFC, let alone IETF 
> approval.
> 
> That said, I agree with the approach, and with the notion that the IETF 
> needn't have a monopoly on EXTERNAL-* mechanisms.

Moreover, we're not likely to have many more variants of EXTERNAL than
-TLS, -IPsec and -IPC.  Sure, I could see some SASL app tunneled over
HTTP with DIGEST-MD5 or HTTP/Negotiate, so maybe EXTERNAL-HTTP.  It's
unlikely that we'd have SASL apps over RPC protocols or over other SASL
apps.  Thus we can expect three, maybe four EXTERNAL-* variants.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJs7j4052323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 12:54:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EJs7ox052322; Tue, 14 Apr 2009 12:54:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJs6C4052311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 14 Apr 2009 12:54:07 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-33-211.pools.spcsdns.net (68-247-33-211.pools.spcsdns.net [68.247.33.211]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EJs2HN002503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 15:54:04 -0400 (EDT)
Date: Tue, 14 Apr 2009 15:54:02 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Simon Josefsson <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-02
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, April 14, 2009 12:48:05 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> Simon,
>
> Overall, this I-D mets my needs.  Thanks!
>
> One issue the I-D needs to discuss is how to establish additional
> EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC or
> EXTERNAL-IPC.  How are names of family members ensured to be unique?  etc.
>
> I suggest that EXTERNAL-* family members be registered in the SASL
> mechanism name table under an Expert Review Required policy.  I rather
> not use "Specification Required" as that overly burdensome, and I don't
> see any particular reason for the IETF to have a monopoly on the design
> of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd likely do so
> outside of the IETF.)

Uh, generally Specification Required is _less_ restrictive than Expert 
Review, as it only requires that you provide a specification rather than 
requiring approval from someone.  Meeting the requirement means providing 
some form of specification; it does not require an RFC, let alone IETF 
approval.

That said, I agree with the approach, and with the notion that the IETF 
needn't have a monopoly on EXTERNAL-* mechanisms.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJpMVa052122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 12:51:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EJpMDa052121; Tue, 14 Apr 2009 12:51:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJpLSU052114 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 12:51:21 -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 n3EJpKlN015047 for <[e-mail]>; Tue, 14 Apr 2009 19:51:20 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3EJpK1x044139 for <[e-mail]>; Tue, 14 Apr 2009 13:51:20 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EJYRwg010774; Tue, 14 Apr 2009 14:34:27 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EJYQag010773; Tue, 14 Apr 2009 14:34:26 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 14:34:26 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 12:06:38PM -0700, Kurt Zeilenga wrote:
> On Apr 14, 2009, at 10:54 AM, Nicolas Williams wrote:
> >But that's precisely why we now must define what channel binding means
> >in the context of SASL.  By "means" I mean: what impact it has on
> >abstract APIs,
> 
> RFC 4422 purposed avoided detailing APIs.  It merely says that  

Nonetheless it contains enough text to derive abstract APIs from.
Certainly there exist concrete SASL APIs.  Avoid the matter all you
want, but the fact is that no one really builds monolythic apps with
embedded TLS and SASL implementations.

> >and, since we've decided to make the use of channel
> 
> >binding negotiable, what impact it has on application protocols.
> 
> No, we've (basically) decided that use of channel binding in SCRAM and  
> GS should be negotiable.   We haven't made any decision that all  
> futures that support channel bindings must do so in a manner which is  
> negotiable.

That's true, but the channel binding type is not negotiated, so that
does impact the abstract APIs (whether you believe in them or not).

Let's short-circuit this discussion as we're going around in circles.
You are asserting that YAP by design can only use unique channel binding
types and, indeed, MUST use channel binding with unique channel binding
types.  And you want this to fit in the SASL channel binding concept,
whether that concept exists as a specification or not.

Fine.  Propose some text, possibly using the alternative approach that I
mentioned: require that applications provide *all* available channel
bindings for all available types for the channel being bound to.  Then
the mechanism can select which one to use.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJmBj6051902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 12:48:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EJmBJh051901; Tue, 14 Apr 2009 12:48:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJm9vN051893 for <[e-mail]>; Tue, 14 Apr 2009 12:48:10 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeToeAB=[e-mail]>; Tue, 14 Apr 2009 20:48:08 +0100
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Tue, 14 Apr 2009 12:48:05 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon,

Overall, this I-D mets my needs.  Thanks!

One issue the I-D needs to discuss is how to establish additional  
EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC  
or EXTERNAL-IPC.  How are names of family members ensured to be  
unique?  etc.

I suggest that EXTERNAL-* family members be registered in the SASL  
mechanism name table under an Expert Review Required policy.  I rather  
not use "Specification Required" as that overly burdensome, and I  
don't see any particular reason for the IETF to have a monopoly on the  
design of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd  
likely do so outside of the IETF.)

In particular, I suggest adding another registration request for  
EXTERNAL-TLS to the the IANA considerations section and then adding  
the statement:

	Registration of additional members of this family requires Expert  
Review [BCPXXXX].

to the end of the section (replacing XXXX with the number of the BCP  
that defines Expert Review).

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJcH8w051244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 12:38:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EJcHJx051242; Tue, 14 Apr 2009 12:38:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJc5Iu051209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 14 Apr 2009 12:38:16 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-33-211.pools.spcsdns.net (68-247-33-211.pools.spcsdns.net [68.247.33.211]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EJbww3001807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 15:38:01 -0400 (EDT)
Date: Tue, 14 Apr 2009 15:37:58 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, April 14, 2009 12:06:38 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> RFC 4422 purposed avoided detailing APIs.

We're talking about abstractions, not API's.

> It merely says that generally
> possible to abstract interfaces between application protocols and a
> framework and between a framework and a mechanisms.  It leaves the
> particulars of what boundaries to draw between components of an
> implementation to the implementation, as well as the particulars of what
> is passed over those boundaries, and when, etc.

Not really.  It _claims_ to do that, but then it goes on to describe what 
is expected of protocols and mechanisms.  It _does_ create an abstraction; 
if it didn't, it would be useless.

For example, we know that mechanisms produce tokens which the protocol is 
expected to transport back and forth, but whose format and semantics are 
known only to the mechanism.  And, we know that the client and server sides 
of a mechanism always take turns producing tokens, so that the protocol can 
transport them via a challenge/response or request/reply sort of exchange.

We know that mechanisms result in either success or failure, but that it is 
up to the protocol to decide how to convey this from server to client.  In 
the case of success, mechanisms also produce an authenticated name, whose 
syntax and semantics are mechanism-specific(*).

We also know that protocols may provide an authorization name, whose syntax 
and semantics are known only to the protocol, but which the mechanism is 
responsible for transporting from client to server, possibly (preferably?) 
in a secure manner.

We know that mechanisms may provide a facility for encryption and/or 
integrity protection of application data exchange after the authentication 
process completes.  We know that when such a layer is in use, it works by 
the protocol passing definite-length chunks of protocol data ("buffers") to 
the mechanism, which transforms them into buffers of protected data in a 
mechanism format.  The protocol is then responsible for transporting the 
protected buffers and handing them to the mechanism on the far end, which 
transforms them back into plain protocol data.


All of this, and more, we know because RFC4422 specifies these things about 
the interaction between protocols and mechanisms, without regard to which 
protocol and which mechanism.  That is an abstract interface.  "Interface" 
does not always mean "C function call API".

What draft-ietf-sasl-channel-bindings does is extend the abstract interface 
defined by RFC4422 to encompass handling of channel bindings.  It does so 
by saying that mechanisms may support channel binding and protocols may 
provide CB data to the mechanism.  When the mechanism supports CB and the 
protocol client and server both provide CB data, then authentication 
succeeds only when the CB data provided on both ends matches.  Like the 
other items listed above, this behavior is and should be independent of 
which protocol and which mechanism is used.

> No, we've (basically) decided that use of channel binding in SCRAM and GS
> should be negotiable.   We haven't made any decision that all futures
> that support channel bindings must do so in a manner which is negotiable.


>> That means we MUST specify what channel
>> binding means in the context of SASL.
>
> In the context of SCRAM certainly.  In general, no.

No, if we do it at all, we must do it at the SASL layer.  Attempting to do 
it only at the SCRAM layer violates the abstraction, by requiring every 
protocol to have mechanism-specific knowledge.  That would defeat the point 
of having SASL in the first place.


>> Did you read the sub-thread we had where Jeff H. commented that the
>> logic for selecting a channel binding type to use needed to be not
>> mechanism-specific?
>
> Yes, and I agree it need not be mechanism specific.  However, I disagree
> that it need be the same in all mechanisms.

Then you missed my point.  The point is _not_ that it does not need to be 
mechanism-specific.  The point is that it _does_ need to _not_ be 
mechanism-specific.  This is how we avoid writing a hundred new RFC's 
whenever someone designs a new mechanism.  It's also how sane application 
protocol implementors avoid having to change their implementations for 
every new mechanism.

If you want to implement every combination of protocol x mechanism 
separately, feel free.  But don't deny me the abstraction that allows me to 
instead implement each protocol once and each mechanism once, and further 
to let someone else do most of that work while I reap the benefits simply 
by changing configuration.

Abstraction is _important_.
Modularity is _important_.

These things provide scalability, and thus feasibility.
These things make the difference between analysis that is too complicated 
to be possible, and analysis that is simple enough to do.

Having channel bindings work the same way for every protocol and for every 
mechanism allows me to analyze how each protocol handles channel bindings 
and how each mechanism handles channel bindings, instead of having to 
separately analyze each combination.  This significantly improves my job in 
promoting the security of my site and of the Internet.


> The point here is that any interface between components of an
> implementation are implementation details, not protocol details.  RFC
> 4422 specifies protocol, not implementation details.

RFC 4422 specifies almost no protocol.
It specifies an abstraction.

> Your I-D gets into details which RFC 4422 left to implementors.  For
> instance, it mandates what and when and how channel binding data is
> passed between two components of implementation.

No, it mandates what and when and how channel binding data is passed 
between abstract components in a (implied) block diagram, which may or may 
not bear any resemblance to an actual implementation.  In the same way that 
RFC4422 mandates what and when and how mechanism tokens or security layer 
buffers are passed between the same abstract components.


-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJ6jO9049223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 12:06:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EJ6juH049221; Tue, 14 Apr 2009 12:06:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EJ6hfc049215 for <[e-mail]>; Tue, 14 Apr 2009 12:06:44 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeTewAB=[e-mail]>; Tue, 14 Apr 2009 20:06:41 +0100
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 12:06:38 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 14, 2009, at 10:54 AM, Nicolas Williams wrote:

>
> On Tue, Apr 14, 2009 at 10:39:14AM -0700, Kurt Zeilenga wrote:
>> On Apr 14, 2009, at 7:39 AM, Jeffrey Hutzelman wrote:
>>> Channel bindings are not a parameter for the mechanism to "use"
>>> however it wants.
>>
>> The point is more that we shouldn't assume there is one and only one
>> channel binding framework.  RFC 5056 and the particulars of this I-D
>> are in their early stage in its adoption, we should be careful not to
>> assume either is the end-all solution to channel bindings.  For
>> instance, it's quite unclear that the dual naming approach is the  
>> end-
>> all negotiation solution (we haven't tried it in the real world yet).
>>
>> Channel binding to me is, I think, still a limited extension to SASL.
>> No well established mechanism uses channel binding, and we only  
>> have a
>> couple presently in the works.
>
> But that's precisely why we now must define what channel binding means
> in the context of SASL.  By "means" I mean: what impact it has on
> abstract APIs,

RFC 4422 purposed avoided detailing APIs.  It merely says that  
generally possible to abstract interfaces between application  
protocols and a framework and between a framework and a mechanisms.   
It leaves the particulars of what boundaries to draw between  
components of an implementation to the implementation, as well as the  
particulars of what is passed over those boundaries, and when, etc.

> and, since we've decided to make the use of channel

> binding negotiable, what impact it has on application protocols.

No, we've (basically) decided that use of channel binding in SCRAM and  
GS should be negotiable.   We haven't made any decision that all  
futures that support channel bindings must do so in a manner which is  
negotiable.

>
>
>> I simply think it's too early to treat channel bindings as if it were
>> a mature feature of SASL.
>
> I don't understand that statement.  We have consensus, I think, for
> SCRAM not providing security layers and for relying on channel binding
> for protection against MITMs.

Yes, but consensus on SCRAM doesn't imply consensus for all future  
mechanisms.

> That means we MUST specify what channel
> binding means in the context of SASL.

In the context of SCRAM certainly.  In general, no.

> Whether what we specify is
> "mature" or not does not enter the picture -- the IETF does not insist
> on deployment before standardization, and I'm surprised to see you
> arguing, effectively, that it does.

We're in the process of revising RFC 4422 for draft standard status,  
so maturity is a factor in what we put into RFC 4422.

But my point was less about IETF process, and more about possibly bad  
assumptions that the solutions we have to day are the end-all  
solutions.  I want to avoid unnecessarily restricting the future  
design of new mechanisms.

>
>
>>> Now, to date your objections have been quite vague.
>>
>> At present, I am trying to focus on the primary issue I have and  
>> hence
>> I haven't attempted to slam each secondary issue I have.  That would
>> be a lot of work, as I have problems with nearly every line of the I-
>> D.  Hence, at present, I intend to focus on the basic premise of  
>> the I-
>> D which I disagree with.
>
> You're not giving us much to work with.  State your objection(s).
> (Though I believe I've figured it out from your reference to YAP, as I
> wrote earlier.)

I gave YAP as only an example of how your assumptions in your I-D  
didn't account for what mechanisms folks might want to reasonable  
design and use.

My point is that your assumption that we today can come up with a  
channel binding solution to end all solutions is a bad assumption.    
We should assume it's a good enough solution for today.  While  
recommending future mechanisms not differ unnecessarily might be  
reasonable, saying they MUST do channel binding as detailed in I-D is,  
IMO, a bad thing.

>
>
>> From section 1:
>>>  The introduction of the Salted Challenge Response (SCRAM) SASL
>>> mechanism [I-D.newman-auth-scram] and GS2 family of SASL mechanisms
>>> [I-D.ietf-sasl-gs2] requires the introduction into SASL of an
>>> abstract interface to channel binding [RFC5056].
>>
>> I simply disagree that the introduction of mechanisms which support
>> channel bindings requires any change to RFC 4422.  While certainly
>> introduction of mechanisms with new features requiring new kinds of
>> information to be provided to it will require changes in
>> implementation to obtain and provide this information, this is  
>> already
>> discussed in RFC 4422.
>
> Did you read the sub-thread we had where Jeff H. commented that the
> logic for selecting a channel binding type to use needed to be not
> mechanism-specific?

Yes, and I agree it need not be mechanism specific.  However, I  
disagree that it need be the same in all mechanisms.

> That's what gave rise to this I-D.  It might help
> for you to comment on Jeff's points.
>
>> And as far as the statements premise referring to a need to establish
>> what the INTERNAL interface between components of an implementation,
>
> I wrote "abstract."  It's definitely NOT an internal interface.  
> We've a

> number of applications available for Linux/Solaris/*BSD/Windows that  
> use
> SASL via a system library.  Those interfaces are most definitely
> public, not internal.

The point here is that any interface between components of an  
implementation are implementation details, not protocol details.  RFC  
4422 specifies protocol, not implementation details.

Your I-D gets into details which RFC 4422 left to implementors.  For  
instance, it mandates what and when and how channel binding data is  
passed between two components of implementation.

>
>
>> such as component primarily implementing an application protocol, a
>> component primarily implement a SASL framework, a component
>> implementing a particular SASL mechanism, a component implementing a
>> lower-lever security service such as TLS, I argue that these are
>> implementation details.
>
> The interfaces between those components must be public interfaces  
> unless
> the application is monolythic (i.e., all the components are from the
> same implementor, tightly integrated, and not separately
> replaceable/updateable).

Whether or not such interfaces are public or private is orthogonal to  
whether the interfaces are implementation details or protocol  
details.  I argue they are not protocol details, they are  
implementation details.

>
>
>>                          RFC 4422 has no business specify what is to
>> passed between such components and when... it shouldn't even make
>> assumptions that such components exist as separate modules of code
>> with distinct abstract interfaces between them.  Very unlike this
>> document, RFC 4422 purposely avoided getting into the details of
>> interfaces between components of an implementation.
>
> Nonsense.  Why even have RFC4422 if there's no room for public SASL
> interfaces?

RFC 4422 provides a conceptional model and a requirement mechanism and  
protocol specifications.  Without ever getting into public SASL  
interfaces, SASL has been widely and successfully deployed.

You appear to argue that channel binding will not being widely and  
successfully deployed unless we get into these implementation  
details.  I think our operational experience with RFC 2222 and RFC  
4422 counters your argument.


-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EIBhv1045474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 11:11:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EIBhCH045473; Tue, 14 Apr 2009 11:11:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EIBgUf045467 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 11:11:43 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3EIBgrm012771 for <[e-mail]>; Tue, 14 Apr 2009 18:11:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3EIBglR043579 for <[e-mail]>; Tue, 14 Apr 2009 12:11:42 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EHskCo010716; Tue, 14 Apr 2009 12:54:46 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EHsk9b010715; Tue, 14 Apr 2009 12:54:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 12:54:46 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 10:39:14AM -0700, Kurt Zeilenga wrote:
> On Apr 14, 2009, at 7:39 AM, Jeffrey Hutzelman wrote:
> >Channel bindings are not a parameter for the mechanism to "use"  
> >however it wants.
> 
> The point is more that we shouldn't assume there is one and only one  
> channel binding framework.  RFC 5056 and the particulars of this I-D  
> are in their early stage in its adoption, we should be careful not to  
> assume either is the end-all solution to channel bindings.  For  
> instance, it's quite unclear that the dual naming approach is the end- 
> all negotiation solution (we haven't tried it in the real world yet).
> 
> Channel binding to me is, I think, still a limited extension to SASL.   
> No well established mechanism uses channel binding, and we only have a  
> couple presently in the works.

But that's precisely why we now must define what channel binding means
in the context of SASL.  By "means" I mean: what impact it has on
abstract APIs, and, since we've decided to make the use of channel
binding negotiable, what impact it has on application protocols.

> I simply think it's too early to treat channel bindings as if it were  
> a mature feature of SASL.

I don't understand that statement.  We have consensus, I think, for
SCRAM not providing security layers and for relying on channel binding
for protection against MITMs.  That means we MUST specify what channel
binding means in the context of SASL.  Whether what we specify is
"mature" or not does not enter the picture -- the IETF does not insist
on deployment before standardization, and I'm surprised to see you
arguing, effectively, that it does.

> >Now, to date your objections have been quite vague.
> 
> At present, I am trying to focus on the primary issue I have and hence  
> I haven't attempted to slam each secondary issue I have.  That would  
> be a lot of work, as I have problems with nearly every line of the I- 
> D.  Hence, at present, I intend to focus on the basic premise of the I- 
> D which I disagree with.

You're not giving us much to work with.  State your objection(s).
(Though I believe I've figured it out from your reference to YAP, as I
wrote earlier.)

> From section 1:
> >   The introduction of the Salted Challenge Response (SCRAM) SASL  
> >mechanism [I-D.newman-auth-scram] and GS2 family of SASL mechanisms  
> >[I-D.ietf-sasl-gs2] requires the introduction into SASL of an  
> >abstract interface to channel binding [RFC5056].
> 
> I simply disagree that the introduction of mechanisms which support  
> channel bindings requires any change to RFC 4422.  While certainly  
> introduction of mechanisms with new features requiring new kinds of  
> information to be provided to it will require changes in  
> implementation to obtain and provide this information, this is already  
> discussed in RFC 4422.

Did you read the sub-thread we had where Jeff H. commented that the
logic for selecting a channel binding type to use needed to be not
mechanism-specific?  That's what gave rise to this I-D.  It might help
for you to comment on Jeff's points.

> And as far as the statements premise referring to a need to establish  
> what the INTERNAL interface between components of an implementation,  

I wrote "abstract."  It's definitely NOT an internal interface.  We've a
number of applications available for Linux/Solaris/*BSD/Windows that use
SASL via a system library.  Those interfaces are most definitely
public, not internal.

> such as component primarily implementing an application protocol, a  
> component primarily implement a SASL framework, a component  
> implementing a particular SASL mechanism, a component implementing a  
> lower-lever security service such as TLS, I argue that these are  
> implementation details.

The interfaces between those components must be public interfaces unless
the application is monolythic (i.e., all the components are from the
same implementor, tightly integrated, and not separately
replaceable/updateable).

>                           RFC 4422 has no business specify what is to  
> passed between such components and when... it shouldn't even make  
> assumptions that such components exist as separate modules of code  
> with distinct abstract interfaces between them.  Very unlike this  
> document, RFC 4422 purposely avoided getting into the details of  
> interfaces between components of an implementation.

Nonsense.  Why even have RFC4422 if there's no room for public SASL
interfaces?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EHdLGC042965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:39:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EHdLbw042964; Tue, 14 Apr 2009 10:39:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EHdJCV042954 for <[e-mail]>; Tue, 14 Apr 2009 10:39:20 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.151] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeTKRQB=[e-mail]>; Tue, 14 Apr 2009 18:39:17 +0100
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 10:39:14 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 14, 2009, at 7:39 AM, Jeffrey Hutzelman wrote:

>
> --On Monday, April 13, 2009 09:48:00 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>>
>>
>> On Apr 13, 2009, at 8:05 PM, Nicolas Williams wrote:
>>
>>>
>>> On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
>>>>
>>>> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
>>>>> I think what we can do then is this: the application MUST provide
>>>>> all
>>>>> the types of channel binding available and the mechanism MUST pick
>>>>> one
>>>>> to use according to the default rules we shall list (prefer
>>>>> tls-server-end-point over tls-unique) or one specified for the
>>>>> mechanism
>>>>> (YAP always insists on tls-unique).
>>>>
>>>> My concern holds:
>>>> My view is that while GS2 mechanisms (such as SCRAM) handle channel
>>>> in similar ways (by design), we should not impose any restriction
>>>> that
>>>> other mechanisms which support channel bindings do so in a like  
>>>> way.
>>>
>>> I don't quite agree.  We're not saying "you can't use the channel
>>> binding as an input to key derivation" or "you can't send the  
>>> channel
>>> binding as is."  What we are saying is: the channel binding type is
>>> not
>>> negotiated, therefore it has to be known from context.
>>
>> No, what you are saying (as I read your I-D) is that future mechanism
>> providing channel bindings MUST do so in a way that similar to a
>> particular set of mechanisms (whether that set is just GS2-* or GS2- 
>> * +
>> YAP is not relevant to my concern).  I don't see stating such
>> restrictions as being appropriate.  While I agree that it is  
>> desirable
>> for future mechanisms not to be unnecessarily different than existing
>> mechanisms, I think rather avoid mandating commonality here and
>> elsewhere.  In RFC 4422, we generally only RECOMMENDED commonality  
>> for
>> certain kinds of information.  This allows for future mechanisms to
>> address issues we haven't yet even thought.
>
>
> Channel bindings are not a parameter for the mechanism to "use"  
> however it wants.

The point is more that we shouldn't assume there is one and only one  
channel binding framework.  RFC 5056 and the particulars of this I-D  
are in their early stage in its adoption, we should be careful not to  
assume either is the end-all solution to channel bindings.  For  
instance, it's quite unclear that the dual naming approach is the end- 
all negotiation solution (we haven't tried it in the real world yet).

Channel binding to me is, I think, still a limited extension to SASL.   
No well established mechanism uses channel binding, and we only have a  
couple presently in the works.

I simply think it's too early to treat channel bindings as if it were  
a mature feature of SASL.

>
>
>
> The purpose of channel bindings is to cryptographically bind a lower- 
> layer channel to the authentication process, in order to eliminate  
> the possibility of a MitM attack.  Channel bindings are passed to a  
> mechanism specifically for this purpose, and the mechanism is  
> expected to indicate whether or not the channel bindings provided at  
> both ends are the same. This is _important_; when an application  
> passes channel bindings to SASL, it is saying "I intend to use this  
> lower-layer channel and to depend on it to protect the integrity and/ 
> or confidentiality of my communication; is that safe?".
>
> For a mechanism to "use" channel binding data in another way, such  
> as was suggested for EXTERNAL, would violate the assumptions of the  
> application in a way that breaks the abstraction, requiring  
> applications to have mechanism-specific knowledge such as "If I'm  
> using SCRAM-PLUS, I should pass in channel bindings corresponding to  
> the channel I want SCRAM to authenticate (which probably doesn't  
> have its own client credentials), but if I'm using EXTERNAL-CHANNEL,  
> I need to pass in channel bindings corresponding to the channel I  
> have already authenticated and whose client authentication I want  
> the mechanism to use".  The first usage is consistent with the  
> purpose of channel bindings; the second is inappropriately  
> overloading them to mean something else.
>
>
> With regard to the needs of YAP, I think it would be fine for a  
> mechanism to have the property that it depends on the channel used  
> to be a unique channel, rather than an endpoint channel.  This would  
> be a property of the mechanism, never something that is negotiated;  
> if you don't _have_ a unique channel to bind to, then YAP should not  
> be advertised.
>
>
>
> Now, to date your objections have been quite vague.

At present, I am trying to focus on the primary issue I have and hence  
I haven't attempted to slam each secondary issue I have.  That would  
be a lot of work, as I have problems with nearly every line of the I- 
D.  Hence, at present, I intend to focus on the basic premise of the I- 
D which I disagree with.

 From section 1:
>    The introduction of the Salted Challenge Response (SCRAM) SASL  
> mechanism [I-D.newman-auth-scram] and GS2 family of SASL mechanisms  
> [I-D.ietf-sasl-gs2] requires the introduction into SASL of an  
> abstract interface to channel binding [RFC5056].


I simply disagree that the introduction of mechanisms which support  
channel bindings requires any change to RFC 4422.  While certainly  
introduction of mechanisms with new features requiring new kinds of  
information to be provided to it will require changes in  
implementation to obtain and provide this information, this is already  
discussed in RFC 4422.

>    While this layer does generally hide the particulars of protocols  
> from mechanisms and the particulars of mechanisms from protocols,
>    this layer does not generally hide the particulars of mechanisms  
> from protocol implementations. For example, different mechanisms
>    require different information to operate, some of them use  
> password-based authentication, some of then require realm  
> information, others make use of Kerberos tickets, certificates, etc.

While one could add "some might support channel bindings" to this  
list, but given it's only a 'for example', that's not necessary.

And as far as the statements premise referring to a need to establish  
what the INTERNAL interface between components of an implementation,  
such as component primarily implementing an application protocol, a  
component primarily implement a SASL framework, a component  
implementing a particular SASL mechanism, a component implementing a  
lower-lever security service such as TLS, I argue that these are  
implementation details.   RFC 4422 has no business specify what is to  
passed between such components and when... it shouldn't even make  
assumptions that such components exist as separate modules of code  
with distinct abstract interfaces between them.  Very unlike this  
document, RFC 4422 purposely avoided getting into the details of  
interfaces between components of an implementation.

Now, what I would suggest is to start with a slight different premise:  
It is desirable for mechanisms supporting channeling binding do so in  
similar manner.  And then to make some RECOMMENDations along this  
line.  Such as adding to Section 5 of RFC 4422,

   SASL mechanisms SHOULD reuse existing channel bindings forms, as  
well as associated syntaxes and semantics, such as detailed in  
[RFC5056].

and then work outward from there (adding some discussion of channel  
binding security considerations, etc.).

I also think that if the WG did want add text in the SASL technical  
specification concerning channel bindings (whatever that text might  
be), that it would be far better to do so as part of revising RFC 4422  
itself instead of an update RFC.   The problem is that while the  
update RFC might read fine (to some) on its own, it doesn't  
necessarily read with in concert with what RFC 4422 says.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EHN9C8041870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:23:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EHN9on041869; Tue, 14 Apr 2009 10:23:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EHN9Kq041863 for <[e-mail]>; Tue, 14 Apr 2009 10:23:09 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EHN8w1003408 for <[e-mail]>; Tue, 14 Apr 2009 17:23:09 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 n3EHN8Ko007914 for <[e-mail]>; Tue, 14 Apr 2009 11:23:08 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EHDhE0010669; Tue, 14 Apr 2009 12:13:43 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EHDhsu010668; Tue, 14 Apr 2009 12:13:43 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 12:13:43 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 06:06:59PM +0100, Alexey Melnikov wrote:
> >>>I removed the part about localization.
> >>>
> >No!  These are purely local localizations, not part of any protocol.
> >There's no need to mention language tags.
> > 
> >
> Well Ok. But the document still needs to say how localization is controlled.

It's a _local_ matter.  Like lots of other APIs.  The localization is to
the caller's _locale_, which is a _local_ matter.

There's nothing more for the spec to say, except perhaps that the
localization is to the caller's locale.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EHDaKc041260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:13:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EHDa7L041259; Tue, 14 Apr 2009 10:13:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EHDPpU041238 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 10:13:36 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3EHDP8L021642 for <[e-mail]>; Tue, 14 Apr 2009 17:13:25 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3EHDPhl064615 for <[e-mail]>; Tue, 14 Apr 2009 11:13:25 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EGuUSL010631; Tue, 14 Apr 2009 11:56:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EGuTUE010630; Tue, 14 Apr 2009 11:56:29 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 11:56:29 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-01
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 09:56:59AM +0200, Simon Josefsson wrote:
> Jeffrey Hutzelman <[e-mail]> writes:
> > I think you have to encode the type of channel to be used for this in
> > the mechanism name, so that it becomes part of the input to mechanism
> > selection.  It would be poor for a client to select EXTERNAL-CHANNEL
> > thinking it's going to get to use credentials from one channel type,
> > only to discover that the server only supports some different type.
> >
> > Unfortunately this does mean you need to register a distinct name for
> > each channel type, but I think that's unavoidable anyway.  The thing
> > we're interested in here is a channel type, not a channel binding
> > type.
> 
> I agree with that.  I have re-read the discussion around
> external-channel-00 and it also leaned towards that approach.
> 
> Thus, I believe the way forward is to define a EXTERNAL-* mechanism
> family and provide one instantiation as EXTERNAL-TLS.

+1



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EH80af040635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:08:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EH801q040634; Tue, 14 Apr 2009 10:08: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.14.2/8.14.2) with ESMTP id n3EH80oD040626 for <[e-mail]>; Tue, 14 Apr 2009 10:08:00 -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 n3EH7x9N015724 for <[e-mail]>; Tue, 14 Apr 2009 17:07:59 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 n3EH0UHB053299 for <[e-mail]>; Tue, 14 Apr 2009 11:00:30 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EGhY1r010598; Tue, 14 Apr 2009 11:43:34 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EGhYNG010597; Tue, 14 Apr 2009 11:43:34 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 11:43:34 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 05:41:27PM +0200, Simon Josefsson wrote:
> Jeffrey Hutzelman <[e-mail]> writes:
> > A GSS-API mechanism spec that allows this to result in an infinite
> > loop is buggy.
> 
> Where is the requirement that makes such behaviour buggy?

We don't need any stinking RFCs to tell us that infinite loops are bugs.

I almost put in a smiley, but I'm too serious about this assertion.
Some things should be self-evident, and this is one of them.  I will not
work on an update to the GSS-API just to make this clarification if it
isn't already clear.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EH7vOc040623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:07:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EH7vsv040622; Tue, 14 Apr 2009 10:07:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EH7kG0040607 for <[e-mail]>; Tue, 14 Apr 2009 10:07:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.166] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SeTC4QB=[e-mail]>; Tue, 14 Apr 2009 18:07:45 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 18:06:59 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <[e-mail]>
CC: Simon Josefsson <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Tue, Apr 14, 2009 at 07:41:35AM +0100, Alexey Melnikov wrote:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>Alexey Melnikov <[e-mail]> writes:
>>>      
>>>
>>>>10.  GSS_Mechanism_SASLname call
>>>>
>>>>To allow SASL implementations to query for the SASL mechanism name of
>>>>a GSS-API mechanism, we specify a new GSS-API function for this
>>>>purpose.
>>>>
>>>>   Inputs:
>>>>
>>>>   o desired_mech OBJECT IDENTIFIER
>>>>
>>>>   Outputs:
>>>>
>>>>   o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>>>>     (really, ASCII)
>>>>
>>>>   o mech_name UTF-8 STRING -- name of this mechanism, possibly
>>>>     localized
>>>>
>>>>   o mech_description UTF-8 STRING -- possibly localized
>>>>     description of this mechanism.
>>>>
>>>>
>>>>With my Apps AD hat on: if you want to allow localization, you need a
>>>>way to control language/local. So a new parameter for language tags is
>>>>needed (see RFC 4646).
>>>>        
>>>>
>>>I removed the part about localization.
>>>      
>>>
>No!  These are purely local localizations, not part of any protocol.
>There's no need to mention language tags.
>  
>
Well Ok. But the document still needs to say how localization is controlled.

>Please restore the text about localization.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGtPx9039470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 09:55:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EGtPE6039469; Tue, 14 Apr 2009 09:55:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGtPil039463 for <[e-mail]>; Tue, 14 Apr 2009 09:55:25 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EGtORP013327 for <[e-mail]>; Tue, 14 Apr 2009 16:55:25 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3EGtOJT049613 for <[e-mail]>; Tue, 14 Apr 2009 10:55:24 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EGjxe2010606; Tue, 14 Apr 2009 11:45:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EGjxiR010605; Tue, 14 Apr 2009 11:45:59 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 11:45:59 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 07:41:35AM +0100, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >Alexey Melnikov <[e-mail]> writes:
> > 
> >>10.  GSS_Mechanism_SASLname call
> >>
> >> To allow SASL implementations to query for the SASL mechanism name of
> >> a GSS-API mechanism, we specify a new GSS-API function for this
> >> purpose.
> >>
> >>    Inputs:
> >>
> >>    o desired_mech OBJECT IDENTIFIER
> >>
> >>    Outputs:
> >>
> >>    o sasl_mech_name OCTET STRING -- SASL name for this mechanism
> >>      (really, ASCII)
> >>
> >>    o mech_name UTF-8 STRING -- name of this mechanism, possibly
> >>      localized
> >>
> >>    o mech_description UTF-8 STRING -- possibly localized
> >>      description of this mechanism.
> >>
> >>
> >>With my Apps AD hat on: if you want to allow localization, you need a
> >>way to control language/local. So a new parameter for language tags is
> >>needed (see RFC 4646).
> >>   
> >>
> >I removed the part about localization.

No!  These are purely local localizations, not part of any protocol.
There's no need to mention language tags.

Please restore the text about localization.

> I am not sure the "mech_name" field is useful.

Possibly not, indeed.  ("EXTERNAL", "PLAIN" could be localized, others
probably not.)

> >The important part is the 'sasl_mech_name' field.
> > 
> >
> Yes.

Not only.  The mech_description is important too for observability.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGooVf039132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 09:50:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EGooDj039131; Tue, 14 Apr 2009 09:50:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGodgJ039108 for <[e-mail]>; Tue, 14 Apr 2009 09:50:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EGodiY011725 for <[e-mail]>; Tue, 14 Apr 2009 16:50:39 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 n3EGodLt045925 for <[e-mail]>; Tue, 14 Apr 2009 10:50:39 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EGfEjl010592; Tue, 14 Apr 2009 11:41:14 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EGfE7s010591; Tue, 14 Apr 2009 11:41:14 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 11:41:14 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 10:06:01AM +0200, Simon Josefsson wrote:
> > Should "p" also be preceeded by "F"?

Only if the GSS mechanism is not a "standard" mechanism -- the "F" means
just that.  The Kerberos V mechanism is and SCRAM will be standard in
the RFC2743 sense, therefore the "F" should NOT be present in the case
of SASL/GS2 w/ Kerberos V or SCRAM.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGmQZt038989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 09:48:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EGmQeE038988; Tue, 14 Apr 2009 09:48:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGmFuU038975 for <[e-mail]>; Tue, 14 Apr 2009 09:48:25 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EGmFJs008847 for <[e-mail]>; Tue, 14 Apr 2009 16:48:15 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 n3EGmE5j043900 for <[e-mail]>; Tue, 14 Apr 2009 10:48:15 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EGcng3010586; Tue, 14 Apr 2009 11:38:49 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EGcnmZ010585; Tue, 14 Apr 2009 11:38:49 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 11:38:49 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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, Apr 14, 2009 at 10:06:01AM +0200, Simon Josefsson wrote:
> 
> Alexey Melnikov <[e-mail]> writes:
> 
> >>>Also, the server SHOULD refrain from sending GSS-API error tokens
> >>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
> >>>along with a major status code other than GSS_S_COMPLETE or
> >>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
> >>>
> >>> I am not sure I agree – SASL error reporting is poor.    
> >>>
> >>Are you asking for GSS-API error tokens to be sent?
> >>  
> >>
> > Yes. I don't see a reason why it shouldn't.
> 
> Nico, what do you think here?
> 
> I don't care strongly.  My experience with GSS-API is that you can't
> expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
> error tokens on failures.  However, that could be seen as a bug.

I don't care strongly, and I don't agree with your experience -- error
tokens are *very* useful.  However, I've had this discussion with Sam in
the past and he's always insisted that there should be an option to not
send error tokens, and the motivation for that is to avoid leaking
information to attackers.

> I don't see any critical problem in allowing error tokens to be sent.

I don't either.  I think we should make that a MAY.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGfdm2038567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 09:41:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EGfdFu038566; Tue, 14 Apr 2009 09:41:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGfSIi038553 for <[e-mail]>; Tue, 14 Apr 2009 09:41:38 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EGfSiB024556 for <[e-mail]>; Tue, 14 Apr 2009 16:41:28 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3EGfS3g038676 for <[e-mail]>; Tue, 14 Apr 2009 10:41:28 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EGW3ob010574; Tue, 14 Apr 2009 11:32:03 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EGW3f7010573; Tue, 14 Apr 2009 11:32:03 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 11:32:03 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 07:54:04AM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >No, absolutely not.  The channel binding type is not being negotiated.
> >
> Why not?

Oh, it could be.  But that's not part of SCRAM nor GS2 at this time.  So
far we did not need it to be negotiable, and I don't think YAP is enough
to make it so we have to make it negotiable (EXTERNAL is not even
relevant to this).

If we want to make the channel binding type negotiable _now_ is the time
to do it, and as with the use of channel binding itself, it will have to
be done as part of the mechanism negotiation.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGdfc2038470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 09:39:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EGdfw3038469; Tue, 14 Apr 2009 09:39:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EGdUrE038455 for <[e-mail]>; Tue, 14 Apr 2009 09:39:40 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EGdUY3009300 for <[e-mail]>; Tue, 14 Apr 2009 16:39:30 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3EGdTlv037119 for <[e-mail]>; Tue, 14 Apr 2009 10:39:29 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3EGU4qr010568; Tue, 14 Apr 2009 11:30:04 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3EGU1f6010567; Tue, 14 Apr 2009 11:30:01 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 14 Apr 2009 11:30:01 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 09:52:23AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > Help who?  Not the mechanism.
> 
> Help server applications to know which security channel layer to look
> for user credentials.  This is under specified in EXTERNAL, and I
> suspect it is one reason EXTERNAL isn't widely supported by, e.g., MUAs
> that support client TLS authentication.

You don't need to name the channel binding or type.  You need only name
the _layer_ where the channel is that EXTERNAL is referring to.

> >> use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS
> >> etc.
> >
> > The server doesn't get to find out what channel binding type was used by
> > looking at the token.  The server has to know a priori.
> 
> Why?

I was referring to GS2 mechanisms there (the GSS-API does not expose
this information).

> If the client tells the server to look for credentials in, e.g., the TLS
> channel, the server can do so.  If that doesn't work, the expected
> outcome is failure.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EG9K5N036260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 09:09:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EG9KJ4036259; Tue, 14 Apr 2009 09:09:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EG9HaW036249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 09:09:19 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtlCG-0006nO-Au for [e-mail]; Tue, 14 Apr 2009 18:09:17 +0200
X-Hashcash: 1:22:090414:[e-mail]::3+fnc3/l0QC5YxeD:DIc3
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: draft-josefsson-sasl-external-channel-02
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::UBWbE4BZyqyNtTpC:8SW4
X-Hashcash: 1:22:090414:[e-mail]::4OyumyqczyWhrGBj:Ez+w
Date: Tue, 14 Apr 2009 18:09:14 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Tue, 14 Apr 2009 09:00:01 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I've updated the EXTERNAL-* draft to avoid referring to the channel
binding document for security channel names.  This made it easier to
discuss TLS specific items.

/Simon

[e-mail] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism Family for External Authentication: EXTERNAL-*
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-02.txt
> 	Pages           : 9
> 	Date            : 2009-04-14
>
> This document describes a way to perform client authentication in the
> Simple Authentication and Security Layer (SASL) framework by
> referring to the end-user authentication provided by an external
> security layer.  We specify a SASL mechanism family EXTERNAL-* and
> one instance EXTERNAL-TLS that rely on the Transport Layer Security
> (TLS) protocol.  This mechanism differs to the existing EXTERNAL
> mechanism by alleviating the a priori assumptions that servers and
> clients needs somehow negotiate out of band which secure channel that
> is intended.  This document also discuss the implementation of
> authorization decisions.
>
> See <http://josefsson.org/external-channel/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EFfVaX033607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 08:41:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EFfV02033606; Tue, 14 Apr 2009 08:41:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EFfT3p033599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 08:41:31 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtklM-0006mq-Qv; Tue, 14 Apr 2009 17:41:29 +0200
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::QxOrWnEOcGH34PLW:0fq
X-Hashcash: 1:22:090414:[e-mail]::sr3OPifk2LTpVuiz:1ce1
X-Hashcash: 1:22:090414:[e-mail]::/rtXdVA2jNzSMrSu:5OIj
Date: Tue, 14 Apr 2009 17:41:27 +0200
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Tue, 14 Apr 2009 10:47:48 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Tuesday, April 14, 2009 11:20:33 AM +0200 Simon Josefsson
> <[e-mail]> wrote:
>
>> I'm not certain of that: if context establishment enters into an error
>> case, sending an error token is expected.  The response to an error
>> token could be another error token.  And so on.  I don't find any text
>> that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
>> say something about this.
>
> A GSS-API mechanism spec that allows this to result in an infinite
> loop is buggy.

Where is the requirement that makes such behaviour buggy?

If there is none in RFC 2743 I think GS2 needs to discuss this.
Further, in that case, I'm not even sure you can claim that it is buggy.

> The simplest way to handle this is for processing of an error token to
> not ever produce an output_token.  More complicated approaches are
> possible, but generally unnecessary, since an "error token" already
> indicates the context establishment is going to fail.

Consider if the receiver is unable to parse an incoming token, and
doesn't know whether it is a normal context token or an error token.
Sending a error token back doesn't seem entirely unreasonable to me.

> In fact, I think it is reasonable for a GSS-API application to assume
> that any context establishment call which produces a major status
> other than GSS_S_CONTINUE_NEEDED does not expect a reply, and thus the
> call should not be made again.

Right, and the GS2 implementation is an GSS-API application here, so the
GS2 document should explain this.

>> Hm.  Thinking more about this, I'm not sure it is possible to send an
>> error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
>> anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
>> should fail.  There is no way to associate a SASL failure with some
>> data, is there?  We could delay the SASL failure though.
>
> Yes, you'd have to delay the SASL failure for a round trip, if the
> error token is emitted by the SASL server.

Right.

Do you have a preference between my 1) and 2) option?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EFbhTo033336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 08:37:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EFbhJi033335; Tue, 14 Apr 2009 08:37:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EFbUQX033321 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 08:37:42 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtkhT-0006mc-SM; Tue, 14 Apr 2009 17:37:28 +0200
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::I6dkwhkkc6Tue+F+:DGN
X-Hashcash: 1:22:090414:[e-mail]::a8QNtBC3ojia5cvE:2/w6
X-Hashcash: 1:22:090414:[e-mail]::+dItFrKZZwcaR11y:YLhg
Date: Tue, 14 Apr 2009 17:37:25 +0200
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Tue, 14 Apr 2009 10:56:41 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Monday, April 13, 2009 11:39:56 PM +0100 Alexey Melnikov
> <[e-mail]> wrote:
>
>> 10.  GSS_Mechanism_SASLname call
>>
>>    To allow SASL implementations to query for the SASL mechanism name of
>>    a GSS-API mechanism, we specify a new GSS-API function for this
>>    purpose.
>>
>>       Inputs:
>>
>>       o desired_mech OBJECT IDENTIFIER
>>
>>       Outputs:
>>
>>       o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>>         (really, ASCII)
>>
>>       o mech_name UTF-8 STRING -- name of this mechanism, possibly
>>         localized
>>
>>       o mech_description UTF-8 STRING -- possibly localized
>>         description of this mechanism.
>>
>>
>> With my Apps AD hat on: if you want to allow localization, you need a way
>> to control language/local. So a new parameter for language tags is needed
>> (see RFC 4646).
>
> Actually, no, you don't, because this is an abstract API, not a
> protocol, and the correct answer is platform- and language-binding
> dependent.  In particular, the correct answer is almost certainly to
> extract the name from a message catalog corresponding to the user's
> current locale, or some platform-specific equivalent.  In any case,
> localization of the GSS-API is definitely _not_ in the scope of the
> SASL WG.

Agreed.

> I think the right thing to do here is to remove the mech_name and
> mech_description outputs, which are not SASL-specific and have nothing
> to do with the purpose of this call.  That information should be
> obtained via a separate GSS_Display_mech call, to be defined in
> KITTEN.

Yup.

> For that matter, this call really ought to be renamed something like
> GSS_Inquire_mech_sasl_name, for consistency with the way the abstract
> GSS-API is defined.

Yes.  I have renamed it to GSS_Inquire_SASLname_for_mech.  I think that
is slightly better because it puts the property to query for first,
which is consistent with the two GSS_Inquire_* support calls.  It also
makes the function name the reverse of the GSS_Inquire_mech_for_SASLname
which also seems good for consistency.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EEukQN029709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 07:56:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EEukgS029707; Tue, 14 Apr 2009 07:56:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EEuiNZ029699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 14 Apr 2009 07:56:45 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EEug8C009243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:56:42 -0400 (EDT)
Date: Tue, 14 Apr 2009 10:56:41 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
cc: [e-mail]
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, April 13, 2009 11:39:56 PM +0100 Alexey Melnikov 
<[e-mail]> wrote:

> 10.  GSS_Mechanism_SASLname call
>
>    To allow SASL implementations to query for the SASL mechanism name of
>    a GSS-API mechanism, we specify a new GSS-API function for this
>    purpose.
>
>       Inputs:
>
>       o desired_mech OBJECT IDENTIFIER
>
>       Outputs:
>
>       o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>         (really, ASCII)
>
>       o mech_name UTF-8 STRING -- name of this mechanism, possibly
>         localized
>
>       o mech_description UTF-8 STRING -- possibly localized
>         description of this mechanism.
>
>
> With my Apps AD hat on: if you want to allow localization, you need a way
> to control language/local. So a new parameter for language tags is needed
> (see RFC 4646).

Actually, no, you don't, because this is an abstract API, not a protocol, 
and the correct answer is platform- and language-binding dependent.  In 
particular, the correct answer is almost certainly to extract the name from 
a message catalog corresponding to the user's current locale, or some 
platform-specific equivalent.  In any case, localization of the GSS-API is 
definitely _not_ in the scope of the SASL WG.

I think the right thing to do here is to remove the mech_name and 
mech_description outputs, which are not SASL-specific and have nothing to 
do with the purpose of this call.  That information should be obtained via 
a separate GSS_Display_mech call, to be defined in KITTEN.

For that matter, this call really ought to be renamed something like 
GSS_Inquire_mech_sasl_name, for consistency with the way the abstract 
GSS-API is defined.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EElr12028935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 07:47:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EElrEZ028933; Tue, 14 Apr 2009 07:47:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EElp3x028925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 14 Apr 2009 07:47:52 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EElmNE008764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:47:49 -0400 (EDT)
Date: Tue, 14 Apr 2009 10:47:48 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: SASL WG <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, April 14, 2009 11:20:33 AM +0200 Simon Josefsson 
<[e-mail]> wrote:

> I'm not certain of that: if context establishment enters into an error
> case, sending an error token is expected.  The response to an error
> token could be another error token.  And so on.  I don't find any text
> that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
> say something about this.

A GSS-API mechanism spec that allows this to result in an infinite loop is 
buggy.  The simplest way to handle this is for processing of an error token 
to not ever produce an output_token.  More complicated approaches are 
possible, but generally unnecessary, since an "error token" already 
indicates the context establishment is going to fail.

In fact, I think it is reasonable for a GSS-API application to assume that 
any context establishment call which produces a major status other than 
GSS_S_CONTINUE_NEEDED does not expect a reply, and thus the call should not 
be made again.


> Hm.  Thinking more about this, I'm not sure it is possible to send an
> error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
> anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
> should fail.  There is no way to associate a SASL failure with some
> data, is there?  We could delay the SASL failure though.

Yes, you'd have to delay the SASL failure for a round trip, if the error 
token is emitted by the SASL server.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EEdoR7028335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 07:39:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EEdoCD028334; Tue, 14 Apr 2009 07:39:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EEdcee028321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 14 Apr 2009 07:39:49 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3EEdYDb008389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 10:39:35 -0400 (EDT)
Date: Tue, 14 Apr 2009 10:39:34 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
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]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, April 13, 2009 09:48:00 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
>
> On Apr 13, 2009, at 8:05 PM, Nicolas Williams wrote:
>
>>
>> On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
>>>
>>> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
>>>> I think what we can do then is this: the application MUST provide
>>>> all
>>>> the types of channel binding available and the mechanism MUST pick
>>>> one
>>>> to use according to the default rules we shall list (prefer
>>>> tls-server-end-point over tls-unique) or one specified for the
>>>> mechanism
>>>> (YAP always insists on tls-unique).
>>>
>>> My concern holds:
>>>  My view is that while GS2 mechanisms (such as SCRAM) handle channel
>>> in similar ways (by design), we should not impose any restriction
>>> that
>>> other mechanisms which support channel bindings do so in a like way.
>>
>> I don't quite agree.  We're not saying "you can't use the channel
>> binding as an input to key derivation" or "you can't send the channel
>> binding as is."  What we are saying is: the channel binding type is
>> not
>> negotiated, therefore it has to be known from context.
>
> No, what you are saying (as I read your I-D) is that future mechanism
> providing channel bindings MUST do so in a way that similar to a
> particular set of mechanisms (whether that set is just GS2-* or GS2-* +
> YAP is not relevant to my concern).  I don't see stating such
> restrictions as being appropriate.  While I agree that it is desirable
> for future mechanisms not to be unnecessarily different than existing
> mechanisms, I think rather avoid mandating commonality here and
> elsewhere.  In RFC 4422, we generally only RECOMMENDED commonality for
> certain kinds of information.  This allows for future mechanisms to
> address issues we haven't yet even thought.


Channel bindings are not a parameter for the mechanism to "use" however it 
wants.


The purpose of channel bindings is to cryptographically bind a lower-layer 
channel to the authentication process, in order to eliminate the 
possibility of a MitM attack.  Channel bindings are passed to a mechanism 
specifically for this purpose, and the mechanism is expected to indicate 
whether or not the channel bindings provided at both ends are the same. 
This is _important_; when an application passes channel bindings to SASL, 
it is saying "I intend to use this lower-layer channel and to depend on it 
to protect the integrity and/or confidentiality of my communication; is 
that safe?".

For a mechanism to "use" channel binding data in another way, such as was 
suggested for EXTERNAL, would violate the assumptions of the application in 
a way that breaks the abstraction, requiring applications to have 
mechanism-specific knowledge such as "If I'm using SCRAM-PLUS, I should 
pass in channel bindings corresponding to the channel I want SCRAM to 
authenticate (which probably doesn't have its own client credentials), but 
if I'm using EXTERNAL-CHANNEL, I need to pass in channel bindings 
corresponding to the channel I have already authenticated and whose client 
authentication I want the mechanism to use".  The first usage is consistent 
with the purpose of channel bindings; the second is inappropriately 
overloading them to mean something else.


With regard to the needs of YAP, I think it would be fine for a mechanism 
to have the property that it depends on the channel used to be a unique 
channel, rather than an endpoint channel.  This would be a property of the 
mechanism, never something that is negotiated; if you don't _have_ a unique 
channel to bind to, then YAP should not be advertised.



Now, to date your objections have been quite vague.  Can you please point 
to one or more specific MUSTs or SHOULDs that you disagree with, and 
explain why?  Otherwise we are going to keep going around in circles 
forever.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EAx5HF009641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 03:59:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EAx5VA009640; Tue, 14 Apr 2009 03:59:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EAx43w009632 for <[e-mail]>; Tue, 14 Apr 2009 03:59:05 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SeRsdwB=[e-mail]>; Tue, 14 Apr 2009 11:59:03 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 11:58:39 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[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=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
> =20
>
>>Simon Josefsson wrote:
>>   =20
>>
>>>Alexey Melnikov <[e-mail]> writes:
>>>     =20
>>>
>>>>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>>>>along with a major status code other than GSS_S_COMPLETE or
>>>>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>>>>
>>>>>>I am not sure I agree =E2=80=93 SASL error reporting is poor.
>>>>>>           =20
>>>>>>
>>>>>Are you asking for GSS-API error tokens to be sent?
>>>>>         =20
>>>>>
>>>>Yes. I don't see a reason why it shouldn't.
>>>>       =20
>>>>
>>>Nico, what do you think here?
>>>
>>>I don't care strongly.  My experience with GSS-API is that you can't
>>>expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
>>>error tokens on failures.  However, that could be seen as a bug.
>>>
>>>I don't see any critical problem in allowing error tokens to be sent.
>>>If we allow it, we need to require that implementations needs to make
>>>sure they don't endlessly send error tokens back and forward, don't we?
>>>Otherwise I think we may end up in an infinite loop.
>>>     =20
>>>
>>IMHO, this would be a bug in a GSS-API mechanism and/or implementation.
>>But it wouldn't hurt to say explicitly.
>>   =20
>>
>
>I'm not certain of that: if context establishment enters into an error
>case, sending an error token is expected.  The response to an error
>token could be another error token.  And so on.  I don't find any text
>that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
>say something about this.
>
>Hm.  Thinking more about this, I'm not sure it is possible to send an
>error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
>anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
>should fail.  There is no way to associate a SASL failure with some
>data, is there?
>
There isn't, but an endpoint can send some data that would cause the=20
other end to fail the authentication exchange.

>We could delay the SASL failure though.
>
>So either we replace the paragraph above with:
>
>		<t>The client and server MUST NOT send any GSS-API
>		    tokens (tokens output by GSS_Init_sec_context() or
>		    GSS_Accept_sec_context() when the major status
>		    code is other than GSS_S_COMPLETE or
>		    GSS_S_CONTINUE_NEEDED) as this indicate an error
>		    situation and the SASL negotiation MUST fail.</t>
>
>Or
>
>		<t>The client and server MAY send GSS-API error tokens
>		    (tokens output by GSS_Init_sec_context() or
>		    GSS_Accept_sec_context() when the major status
>		    code is other than GSS_S_COMPLETE or
>		    GSS_S_CONTINUE_NEEDED).  As this indicate an error
>		    condition, after sending the token, the sending
>		    side should fail the authentication.</t>
>
>Is there any other option?
> =20
>
I can't think of any.
Obviously, I prefer the latter.

>Thoughts?
>
>I suspect Nico have some insight into this.
> =20
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EA07XI004117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 03:00:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EA07aa004116; Tue, 14 Apr 2009 03:00:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EA05Z8004109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 03:00:07 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtfQz-0006Ro-2e; Tue, 14 Apr 2009 12:00:05 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::y+3eJW2u7WaJiTj8:BlRt
X-Hashcash: 1:22:090414:[e-mail]::dWuEKMQ+rwg0vO0J:Sedv
Date: Tue, 14 Apr 2009 12:00:04 +0200
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Tue, 14 Apr 2009 10:06:01 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson <[e-mail]> writes:

>>>>Example #4: using channel binding.
>>>>
>>>>C: Request authentication exchange
>>>>S: Empty Challenge
>>>>C: yauthzid=someuser, <initial context token with standard
>>>>
>>>>Should this start with “p”?
>>>>
>>>>header removed>
>>>> S: Send reply context token as is    
>>>>
>>>Yes.
>>>
>> Should "p" also be preceeded by "F"?
>
> Yes.

No, this was wrong -- the only time the "F" should be present is when
the client were unable to remove the standard GSS-API token header.  I
tried to clarify the document, and fixed the examples.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E9vs4B003895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 02:57:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E9vsMQ003894; Tue, 14 Apr 2009 02:57:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E9vqHf003885 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 02:57:54 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtfOo-0006QM-M6 for [e-mail]; Tue, 14 Apr 2009 11:57:52 +0200
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: GS2: always use header compression?
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::+2ETo5sTW8We+X3h:7/DD
Date: Tue, 14 Apr 2009 11:57:49 +0200
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Tue, 14 Apr 2009 11:40:40 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Never mind, I had misunderstood the purpose of the "F" flag.

I have tried to clarify the document to possibly avoid others from
having the same misunderstanding.  New document:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
Diff against last version:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html

I'll wait some days for the current discussions to settle down and then
submit an update.

/Simon

Simon Josefsson <[e-mail]> writes:

> Thinking about implementing GS2, handling the gs2-std-mech ("F") flag
> seems complicated.  Is there any reason why GS2 cannot always require
> clients to remove the header and servers to add it?
>
> I believe this would lead to more robust code paths in implementations
> (i.e., removing and adding the token is always done).  It also reduces
> protocol complexity in that there are fewer ways GS2 can be negotiated.
> This reduces the number of protocol variations that can be deployed,
> which likely leads to better interoperability.
>
> Thus I propose to remove the gs2-std-mech "F" flag and update the text
> to require clients/server to always perform this step.  SCRAM doesn't
> need any update, -12 doesn't seem to send a "F" at all and doesn't
> discuss it.
>
> /Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E9ei0P002829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 02:40:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E9eidB002828; Tue, 14 Apr 2009 02:40:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E9egkq002822 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 02:40:44 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Ltf8D-0006Gg-RX for [e-mail]; Tue, 14 Apr 2009 11:40:42 +0200
X-Hashcash: 1:22:090414:[e-mail]::viqmIMK4/MG5a06L:zL+
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: GS2: always use header compression?
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 11:40:40 +0200
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thinking about implementing GS2, handling the gs2-std-mech ("F") flag
seems complicated.  Is there any reason why GS2 cannot always require
clients to remove the header and servers to add it?

I believe this would lead to more robust code paths in implementations
(i.e., removing and adding the token is always done).  It also reduces
protocol complexity in that there are fewer ways GS2 can be negotiated.
This reduces the number of protocol variations that can be deployed,
which likely leads to better interoperability.

Thus I propose to remove the gs2-std-mech "F" flag and update the text
to require clients/server to always perform this step.  SCRAM doesn't
need any update, -12 doesn't seem to send a "F" at all and doesn't
discuss it.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E9KcbZ001627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 02:20:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E9KctN001626; Tue, 14 Apr 2009 02:20:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E9KaX5001617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 02:20:37 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lteok-00065J-8r; Tue, 14 Apr 2009 11:20:34 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::oJurI6bcfdMBsg/6:EQAt
X-Hashcash: 1:22:090414:[e-mail]::2fQLRgTVCH0d/vqF:hlMF
Date: Tue, 14 Apr 2009 11:20:33 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Tue, 14 Apr 2009 09:52:57 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <[e-mail]> writes:
>>  
>>
>>>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>>>along with a major status code other than GSS_S_COMPLETE or
>>>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>>>
>>>>> I am not sure I agree – SASL error reporting is poor.           
>>>>>
>>>>Are you asking for GSS-API error tokens to be sent?
>>>>      
>>>>
>>>Yes. I don't see a reason why it shouldn't.
>>>    
>>>
>>Nico, what do you think here?
>>
>>I don't care strongly.  My experience with GSS-API is that you can't
>>expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
>>error tokens on failures.  However, that could be seen as a bug.
>>
>>I don't see any critical problem in allowing error tokens to be sent.
>>If we allow it, we need to require that implementations needs to make
>>sure they don't endlessly send error tokens back and forward, don't we?
>>Otherwise I think we may end up in an infinite loop.
>>  
>>
> IMHO, this would be a bug in a GSS-API mechanism and/or implementation.
> But it wouldn't hurt to say explicitly.

I'm not certain of that: if context establishment enters into an error
case, sending an error token is expected.  The response to an error
token could be another error token.  And so on.  I don't find any text
that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
say something about this.

Hm.  Thinking more about this, I'm not sure it is possible to send an
error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
should fail.  There is no way to associate a SASL failure with some
data, is there?  We could delay the SASL failure though.

So either we replace the paragraph above with:

		<t>The client and server MUST NOT send any GSS-API
		    tokens (tokens output by GSS_Init_sec_context() or
		    GSS_Accept_sec_context() when the major status
		    code is other than GSS_S_COMPLETE or
		    GSS_S_CONTINUE_NEEDED) as this indicate an error
		    situation and the SASL negotiation MUST fail.</t>

Or

		<t>The client and server MAY send GSS-API error tokens
		    (tokens output by GSS_Init_sec_context() or
		    GSS_Accept_sec_context() when the major status
		    code is other than GSS_S_COMPLETE or
		    GSS_S_CONTINUE_NEEDED).  As this indicate an error
		    condition, after sending the token, the sending
		    side should fail the authentication.</t>

Is there any other option?

Thoughts?

I suspect Nico have some insight into this.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E8rk2f000141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 01:53:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E8rjUs000140; Tue, 14 Apr 2009 01:53:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E8rYOE000131 for <[e-mail]>; Tue, 14 Apr 2009 01:53:45 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.59.17] (92.40.59.17.sub.mbb.three.co.uk [92.40.59.17])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SeRPDAB=[e-mail]>; Tue, 14 Apr 2009 09:53:33 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 09:52:57 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
> =20
>
>>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>>along with a major status code other than GSS_S_COMPLETE or
>>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>>
>>>>I am not sure I agree =E2=80=93 SASL error reporting is poor.   =20
>>>>       =20
>>>>
>>>Are you asking for GSS-API error tokens to be sent?
>>>     =20
>>>
>>Yes. I don't see a reason why it shouldn't.
>>   =20
>>
>Nico, what do you think here?
>
>I don't care strongly.  My experience with GSS-API is that you can't
>expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
>error tokens on failures.  However, that could be seen as a bug.
>
>I don't see any critical problem in allowing error tokens to be sent.
>If we allow it, we need to require that implementations needs to make
>sure they don't endlessly send error tokens back and forward, don't we?
>Otherwise I think we may end up in an infinite loop.
> =20
>
IMHO, this would be a bug in a GSS-API mechanism and/or implementation.
But it wouldn't hurt to say explicitly.

>>>I agree with you that SASL error reporting is poor, but I'm not sure
>>>sending GSS-API error tokens will help -- the problem is typically the
>>>APIs between the SASL library and the application.  Also, GSS-API error
>>>reporting is also generally poor (e.g., no localization).
>>>     =20
>>>
>>[...]
>>   =20
>>
>>>>Example #4: using channel binding.
>>>>
>>>>C: Request authentication exchange
>>>>S: Empty Challenge
>>>>C: yauthzid=3Dsomeuser, <initial context token with standard
>>>>
>>>>Should this start with =E2=80=9Cp=E2=80=9D?
>>>>
>>>>header removed>
>>>>S: Send reply context token as is
>>>>       =20
>>>>
>>>Yes.
>>>     =20
>>>
>>Should "p" also be preceeded by "F"?
>>   =20
>>
>Yes.  I also noticed it should use 'a=3Dsomeuser' instead of
>'authzid=3Dsomeuser'.
>
>However, it would be nice with more detailed examples and explaining
>text.
> =20
>
Oh, good point.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E8DVxg098102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 01:13:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E8DVqp098101; Tue, 14 Apr 2009 01:13:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E8DTLi098094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 01:13:30 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Ltdlo-0005sX-9Z; Tue, 14 Apr 2009 10:13:28 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::lFAOwWpiKi0WrzOy:09S
X-Hashcash: 1:22:090414:[e-mail]::gYlY5qZvFmtAqi07:08RWS
Date: Tue, 14 Apr 2009 10:13:27 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Tue, 14 Apr 2009 07:41:35 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

>>I removed the part about localization.
>>
> Actually, I am not convinced this is sufficient.
>
>>Frankly, I'm not sure the
>>'mech_name' and 'mech_description' fields are useful.
>>
> I am not sure the "mech_name" field is useful.
>
>>The important part is the 'sasl_mech_name' field.
>>  
>>
> Yes.

I agree.  I've removed mech_name and mech_description from the document
now.  The fields are not used by GS2.  They are just a nice thing to
have for GSS-API generally.  Spending time to add it and fix
localization doesn't seem like the best use of our time.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E86710097506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 01:06:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E867YP097505; Tue, 14 Apr 2009 01:06:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E864mO097497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 01:06:06 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Ltdec-0005sK-SM; Tue, 14 Apr 2009 10:06:04 +0200
X-Hashcash: 1:22:090414:[e-mail]::mMnwSH8+JKXgvz+N:SAm
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::Ehq0cVkIxXr1zBwE:83l3
Date: Tue, 14 Apr 2009 10:06:01 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Tue, 14 Apr 2009 07:35:30 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>along with a major status code other than GSS_S_COMPLETE or
>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>
>>> I am not sure I agree – SASL error reporting is poor.    
>>>
>>Are you asking for GSS-API error tokens to be sent?
>>  
>>
> Yes. I don't see a reason why it shouldn't.

Nico, what do you think here?

I don't care strongly.  My experience with GSS-API is that you can't
expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
error tokens on failures.  However, that could be seen as a bug.

I don't see any critical problem in allowing error tokens to be sent.
If we allow it, we need to require that implementations needs to make
sure they don't endlessly send error tokens back and forward, don't we?
Otherwise I think we may end up in an infinite loop.

>>I agree with you that SASL error reporting is poor, but I'm not sure
>>sending GSS-API error tokens will help -- the problem is typically the
>>APIs between the SASL library and the application.  Also, GSS-API error
>>reporting is also generally poor (e.g., no localization).
>>
> [...]
>
>>>Example #4: using channel binding.
>>>
>>>C: Request authentication exchange
>>>S: Empty Challenge
>>>C: yauthzid=someuser, <initial context token with standard
>>>
>>>Should this start with “p”?
>>>
>>>header removed>
>>> S: Send reply context token as is    
>>>
>>Yes.
>>
> Should "p" also be preceeded by "F"?

Yes.  I also noticed it should use 'a=someuser' instead of
'authzid=someuser'.

However, it would be nice with more detailed examples and explaining
text.

> [...]
>
>>>The channel binding data MAY be sent (byt the actual GSS-API
>>>
>>>Typo: by
>>>    
>>>
> I've changed "byt" to "but"?

Should be fixed.

>>>mechanism used) without confidentiality protection and knowledge of
>>>it is assumed to provide no advantage to an MITM (who can, in any
>>>case, compute the channel binding data independently). If the
>>>external channel does not provide confidentiality protection and the
>>>GSS-API mechanism does not provide confidentiality protection for the
>>>channel binding data, then passive attackers (eavesdroppers) can
>>>recover the channel binding data. See [RFC5056].
>>>
>>>[…]
>>>
>>>GS2 does not directly use any cryptographic algorithms, therefore it
>>>is automatically "algorithm agile", or, as agile as the GSS-API
>>>mechanisms that are available for use in SASL apoplications via GS2.
>>>
>>> Typo: applications    
>>>
>>Thanks.
>>
>>Updated document:
>>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
>>
>>Changes compared to -11:
>>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html
>>
> Other changes look good. (I am still thinking about your SASLPrep response)

Compare RFC 4616:

   The authorization identity (authzid), authentication identity
   (authcid), password (passwd), and NUL character deliminators SHALL be
   transferred as [UTF-8] encoded strings of [Unicode] characters.  As
   the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
   character MUST NOT appear in authzid, authcid, or passwd productions.

   The form of the authzid production is specific to the application-
   level protocol's SASL profile [SASL].  The authcid and passwd
   productions are form-free.  Use of non-visible characters or
   characters that a user may be unable to enter on some keyboards is
   discouraged.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E7v4Ir096980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 00:57:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E7v4mL096979; Tue, 14 Apr 2009 00:57:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E7v2Vd096972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 00:57:03 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtdVs-0005sF-Jn; Tue, 14 Apr 2009 09:57:00 +0200
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-01
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::C6h8+2ZcL0Yi5u3e:1s2m
X-Hashcash: 1:22:090414:[e-mail]::dZqIvVoh9pk3uj94:8mAC
Date: Tue, 14 Apr 2009 09:56:59 +0200
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Mon, 13 Apr 2009 23:41:05 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Tuesday, April 14, 2009 01:52:27 AM +0200 Simon Josefsson
> <[e-mail]> wrote:
>
>>
>> All,
>>
>> I've noticed some renewed interest in an EXTERNAL variant that refers to
>> an outer TLS channel, so I updated my earlier EXTERNAL-CHANNEL document.
>>
>> There is one open issue: whether it is worthwhile to reference RFC 5056
>> for channel names, or whether the document should go ahead and define a
>> EXTERNAL-TLS mechanism directly.  That would refer directly to an outer
>> TLS channel.  It could also reserve EXTERNAL-* for other external
>> security channels.  I don't care strongly, but I do suspect that
>> interoperability will be better with the EXTERNAL-TLS approach (as there
>> are multiple channel names for TLS channels already, and more are
>> proposed).
>
> I think you have to encode the type of channel to be used for this in
> the mechanism name, so that it becomes part of the input to mechanism
> selection.  It would be poor for a client to select EXTERNAL-CHANNEL
> thinking it's going to get to use credentials from one channel type,
> only to discover that the server only supports some different type.
>
> Unfortunately this does mean you need to register a distinct name for
> each channel type, but I think that's unavoidable anyway.  The thing
> we're interested in here is a channel type, not a channel binding
> type.

I agree with that.  I have re-read the discussion around
external-channel-00 and it also leaned towards that approach.

Thus, I believe the way forward is to define a EXTERNAL-* mechanism
family and provide one instantiation as EXTERNAL-TLS.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E7qdIA096674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 00:52:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E7qdGo096673; Tue, 14 Apr 2009 00:52:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E7qRCX096663 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 14 Apr 2009 00:52:38 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtdRQ-0005s8-5m; Tue, 14 Apr 2009 09:52:25 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::WOdbP9qND/DTLY6O:0368
X-Hashcash: 1:22:090414:[e-mail]::3ttnNrg1MQX7i7Cg:UM3s
X-Hashcash: 1:22:090414:[e-mail]::eHPIKIc60ZwxoGAq:0YQ0Z
Date: Tue, 14 Apr 2009 09:52:23 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 13 Apr 2009 22:01:19 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Apr 14, 2009 at 02:19:35AM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > For EXTERNAL the app will just have to retrieve the authenticated ID
>> > itself.
>> 
>> The name of the channel will help, though.  Then the app will know to
>                                    ^
> Help who?  Not the mechanism.

Help server applications to know which security channel layer to look
for user credentials.  This is under specified in EXTERNAL, and I
suspect it is one reason EXTERNAL isn't widely supported by, e.g., MUAs
that support client TLS authentication.

>> use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS
>> etc.
>
> The server doesn't get to find out what channel binding type was used by
> looking at the token.  The server has to know a priori.

Why?

If the client tells the server to look for credentials in, e.g., the TLS
channel, the server can do so.  If that doesn't work, the expected
outcome is failure.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E6seL9093446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 23:54:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E6seZ7093445; Mon, 13 Apr 2009 23:54:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E6sdsj093439 for <[e-mail]>; Mon, 13 Apr 2009 23:54:39 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.59.17] (92.40.59.17.sub.mbb.three.co.uk [92.40.59.17])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SeQzKwB=[e-mail]>; Tue, 14 Apr 2009 07:54:37 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 07:54:04 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <[e-mail]>
CC: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Mon, Apr 13, 2009 at 05:47:13PM -0700, Kurt Zeilenga wrote:
>  
>
>>On Apr 13, 2009, at 4:47 PM, Nicolas Williams wrote:
>>    
>>
>>>On Mon, Apr 13, 2009 at 06:07:21PM -0500, Nicolas Williams wrote:
>>>      
>>>
>>>>You're conflating unrelated things.
>>>>        
>>>>
>>I agree I was conflating issues.
>>
>>The use of the channel binding information would be merely to allow  
>>the client to identify to the server which channel to pull the  
>>authentication identity from.
>>    
>>
>No, absolutely not.  The channel binding type is not being negotiated.
>  
>
Why not?

>The only things we're negotiating are: which mechanism, and whether to
>do channel binding.  Thus the channel binding type has to be agreed upon
>from context and a priori.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E6gAR6092669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 23:42:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E6gAJ2092668; Mon, 13 Apr 2009 23:42:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E6g9KP092659 for <[e-mail]>; Mon, 13 Apr 2009 23:42:09 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.59.17] (92.40.59.17.sub.mbb.three.co.uk [92.40.59.17])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SeQwPQB=[e-mail]>; Tue, 14 Apr 2009 07:42:06 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 07:41:35 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>10.  GSS_Mechanism_SASLname call
>>
>>  To allow SASL implementations to query for the SASL mechanism name of
>>  a GSS-API mechanism, we specify a new GSS-API function for this
>>  purpose.
>>
>>     Inputs:
>>
>>     o desired_mech OBJECT IDENTIFIER
>>
>>     Outputs:
>>
>>     o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>>       (really, ASCII)
>>
>>     o mech_name UTF-8 STRING -- name of this mechanism, possibly
>>       localized
>>
>>     o mech_description UTF-8 STRING -- possibly localized
>>       description of this mechanism.
>>
>>
>>With my Apps AD hat on: if you want to allow localization, you need a
>>way to control language/local. So a new parameter for language tags is
>>needed (see RFC 4646).
>>    
>>
>I removed the part about localization.
>
Actually, I am not convinced this is sufficient.

>Frankly, I'm not sure the
>'mech_name' and 'mech_description' fields are useful.
>
I am not sure the "mech_name" field is useful.

>The important part is the 'sasl_mech_name' field.
>  
>
Yes.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E6a29q092372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 23:36:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E6a2bB092371; Mon, 13 Apr 2009 23:36:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E6a0LE092364 for <[e-mail]>; Mon, 13 Apr 2009 23:36:01 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.59.17] (92.40.59.17.sub.mbb.three.co.uk [92.40.59.17])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SeQuzgB=[e-mail]>; Tue, 14 Apr 2009 07:35:59 +0100
Message-ID: <[e-mail]>
Date: Tue, 14 Apr 2009 07:35:30 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

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

>>In Section 4.1:
>>
>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>along with a major status code other than GSS_S_COMPLETE or
>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>
>>I am not sure I agree =E2=80=93 SASL error reporting is poor.   =20
>>
>Are you asking for GSS-API error tokens to be sent?
> =20
>
Yes. I don't see a reason why it shouldn't.

>I agree with you that SASL error reporting is poor, but I'm not sure
>sending GSS-API error tokens will help -- the problem is typically the
>APIs between the SASL library and the application.  Also, GSS-API error
>reporting is also generally poor (e.g., no localization).
>
 [...]

>>Example #4: using channel binding.
>>
>>C: Request authentication exchange
>>S: Empty Challenge
>>C: yauthzid=3Dsomeuser, <initial context token with standard
>>
>>Should this start with =E2=80=9Cp=E2=80=9D?
>>
>>header removed>
>>S: Send reply context token as is   =20
>>
>Yes.
>
Should "p" also be preceeded by "F"?
 [...]

>>The channel binding data MAY be sent (byt the actual GSS-API
>>
>>Typo: by
>>   =20
>>
I've changed "byt" to "but"?

>>mechanism used) without confidentiality protection and knowledge of
>>it is assumed to provide no advantage to an MITM (who can, in any
>>case, compute the channel binding data independently). If the
>>external channel does not provide confidentiality protection and the
>>GSS-API mechanism does not provide confidentiality protection for the
>>channel binding data, then passive attackers (eavesdroppers) can
>>recover the channel binding data. See [RFC5056].
>>
>>[=E2=80=A6]
>>
>>GS2 does not directly use any cryptographic algorithms, therefore it
>>is automatically "algorithm agile", or, as agile as the GSS-API
>>mechanisms that are available for use in SASL apoplications via GS2.
>>
>>Typo: applications   =20
>>
>Thanks.
>
>Updated document:
>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
>
>Changes compared to -11:
>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html
>
Other changes look good. (I am still thinking about your SASLPrep response)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E4mGcd086628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 21:48:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E4mGL2086627; Mon, 13 Apr 2009 21:48:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E4m5go086620 for <[e-mail]>; Mon, 13 Apr 2009 21:48:15 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeQVgwB=fj=[e-mail]>; Tue, 14 Apr 2009 05:48:04 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 21:48:00 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 13, 2009, at 8:05 PM, Nicolas Williams wrote:

>
> On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
>>
>> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
>>> I think what we can do then is this: the application MUST provide  
>>> all
>>> the types of channel binding available and the mechanism MUST pick  
>>> one
>>> to use according to the default rules we shall list (prefer
>>> tls-server-end-point over tls-unique) or one specified for the
>>> mechanism
>>> (YAP always insists on tls-unique).
>>
>> My concern holds:
>>  My view is that while GS2 mechanisms (such as SCRAM) handle channel
>> in similar ways (by design), we should not impose any restriction  
>> that
>> other mechanisms which support channel bindings do so in a like way.
>
> I don't quite agree.  We're not saying "you can't use the channel
> binding as an input to key derivation" or "you can't send the channel
> binding as is."  What we are saying is: the channel binding type is  
> not
> negotiated, therefore it has to be known from context.

No, what you are saying (as I read your I-D) is that future mechanism  
providing channel bindings MUST do so in a way that similar to a  
particular set of mechanisms (whether that set is just GS2-* or GS2-*  
+ YAP is not relevant to my concern).  I don't see stating such  
restrictions as being appropriate.  While I agree that it is desirable  
for future mechanisms not to be unnecessarily different than existing  
mechanisms, I think rather avoid mandating commonality here and  
elsewhere.  In RFC 4422, we generally only RECOMMENDED commonality for  
certain kinds of information.  This allows for future mechanisms to  
address issues we haven't yet even thought.

-- Kurt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3fL1A083729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 20:41:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E3fLWa083728; Mon, 13 Apr 2009 20:41:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3f9EZ083692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 13 Apr 2009 20:41:20 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3E3f55F026832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 23:41:06 -0400 (EDT)
Date: Mon, 13 Apr 2009 23:41:05 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: draft-josefsson-sasl-external-channel-01
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, April 14, 2009 01:52:27 AM +0200 Simon Josefsson 
<[e-mail]> wrote:

>
> All,
>
> I've noticed some renewed interest in an EXTERNAL variant that refers to
> an outer TLS channel, so I updated my earlier EXTERNAL-CHANNEL document.
>
> There is one open issue: whether it is worthwhile to reference RFC 5056
> for channel names, or whether the document should go ahead and define a
> EXTERNAL-TLS mechanism directly.  That would refer directly to an outer
> TLS channel.  It could also reserve EXTERNAL-* for other external
> security channels.  I don't care strongly, but I do suspect that
> interoperability will be better with the EXTERNAL-TLS approach (as there
> are multiple channel names for TLS channels already, and more are
> proposed).

I think you have to encode the type of channel to be used for this in the 
mechanism name, so that it becomes part of the input to mechanism 
selection.  It would be poor for a client to select EXTERNAL-CHANNEL 
thinking it's going to get to use credentials from one channel type, only 
to discover that the server only supports some different type.

Unfortunately this does mean you need to register a distinct name for each 
channel type, but I think that's unavoidable anyway.  The thing we're 
interested in here is a channel type, not a channel binding type.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3F6Rg081953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 20:15:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E3F6us081952; Mon, 13 Apr 2009 20:15:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3EtKQ081934 for <[e-mail]>; Mon, 13 Apr 2009 20:15:05 -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 n3E3EtJ8012138 for <[e-mail]>; Tue, 14 Apr 2009 03:14:55 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 n3E3EtLC030594 for <[e-mail]>; Mon, 13 Apr 2009 21:14:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3E35Ud5010377; Mon, 13 Apr 2009 22:05:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3E35Ux2010376; Mon, 13 Apr 2009 22:05:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 13 Apr 2009 22:05:30 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
> 
> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
> >I think what we can do then is this: the application MUST provide all
> >the types of channel binding available and the mechanism MUST pick one
> >to use according to the default rules we shall list (prefer
> >tls-server-end-point over tls-unique) or one specified for the  
> >mechanism
> >(YAP always insists on tls-unique).
> 
> My concern holds:
>   My view is that while GS2 mechanisms (such as SCRAM) handle channel  
> in similar ways (by design), we should not impose any restriction that  
> other mechanisms which support channel bindings do so in a like way.

I don't quite agree.  We're not saying "you can't use the channel
binding as an input to key derivation" or "you can't send the channel
binding as is."  What we are saying is: the channel binding type is not
negotiated, therefore it has to be known from context.

Ignoring YAP the relevant context is: the use or non-use of a TLS server
cert.  To allow for YAP we need to make the relevant context be
mechanism-specific (for YAP: always tls-unique, for all others so far:
the use or non-use of a TLS server cert).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3C6NQ081715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 20:12:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E3C6cw081714; Mon, 13 Apr 2009 20:12:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3BusG081695 for <[e-mail]>; Mon, 13 Apr 2009 20:12:06 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3E3BukV005190 for <[e-mail]>; Tue, 14 Apr 2009 03:11:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3E3BtRj029308 for <[e-mail]>; Mon, 13 Apr 2009 21:11:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3E32VOc010371; Mon, 13 Apr 2009 22:02:31 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3E32Vj2010370; Mon, 13 Apr 2009 22:02:31 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 13 Apr 2009 22:02:31 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 13, 2009 at 05:47:13PM -0700, Kurt Zeilenga wrote:
> 
> On Apr 13, 2009, at 4:47 PM, Nicolas Williams wrote:
> 
> >
> >On Mon, Apr 13, 2009 at 06:07:21PM -0500, Nicolas Williams wrote:
> >>You're conflating unrelated things.
> 
> I agree I was conflating issues.
> 
> The use of the channel binding information would be merely to allow  
> the client to identify to the server which channel to pull the  
> authentication identity from.

No, absolutely not.  The channel binding type is not being negotiated.
The only things we're negotiating are: which mechanism, and whether to
do channel binding.  Thus the channel binding type has to be agreed upon
from context and a priori.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3Avf2081629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 20:10:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E3AvVS081628; Mon, 13 Apr 2009 20:10:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E3Ajjj081611 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 13 Apr 2009 20:10:56 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3E3Ajr6003661 for <[e-mail]>; Tue, 14 Apr 2009 03:10:45 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 n3E3AjM4028836 for <[e-mail]>; Mon, 13 Apr 2009 21:10:45 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3E31KhL010365; Mon, 13 Apr 2009 22:01:20 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3E31JN3010364; Mon, 13 Apr 2009 22:01:19 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 13 Apr 2009 22:01:19 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Apr 14, 2009 at 02:19:35AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > For EXTERNAL the app will just have to retrieve the authenticated ID
> > itself.
> 
> The name of the channel will help, though.  Then the app will know to
                                   ^
Help who?  Not the mechanism.

> use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS
> etc.

The server doesn't get to find out what channel binding type was used by
looking at the token.  The server has to know a priori.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E2cY18079817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 19:38:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E2cYuT079816; Mon, 13 Apr 2009 19:38:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E2cWFb079810 for <[e-mail]>; Mon, 13 Apr 2009 19:38:33 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeP3JQB=[e-mail]>; Tue, 14 Apr 2009 03:38:30 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 19:38:26 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
> I think what we can do then is this: the application MUST provide all
> the types of channel binding available and the mechanism MUST pick one
> to use according to the default rules we shall list (prefer
> tls-server-end-point over tls-unique) or one specified for the  
> mechanism
> (YAP always insists on tls-unique).

My concern holds:
   My view is that while GS2 mechanisms (such as SCRAM) handle channel  
in similar ways (by design), we should not impose any restriction that  
other mechanisms which support channel bindings do so in a like way.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E0lT8S073689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 17:47:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E0lSqi073687; Mon, 13 Apr 2009 17:47:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E0lHjm073669 for <[e-mail]>; Mon, 13 Apr 2009 17:47:28 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.181] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SePdEwB=[e-mail]>; Tue, 14 Apr 2009 01:47:16 +0100
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 17:47:13 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 13, 2009, at 4:47 PM, Nicolas Williams wrote:

>
> On Mon, Apr 13, 2009 at 06:07:21PM -0500, Nicolas Williams wrote:
>> You're conflating unrelated things.

I agree I was conflating issues.

The use of the channel binding information would be merely to allow  
the client to identify to the server which channel to pull the  
authentication identity from.

I won't raise EXTERNAL in this thread again (if you don't :-).

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E0Je43071896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 17:19:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E0Jd3g071894; Mon, 13 Apr 2009 17:19:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E0Jbk7071883 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Apr 2009 17:19:39 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtWNE-0005V0-38; Tue, 14 Apr 2009 02:19:36 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090414:[e-mail]::PySK8oijroB/hXGt:OqWt
X-Hashcash: 1:22:090414:[e-mail]::xHaxGv02KCCJxiq1:VgzV
X-Hashcash: 1:22:090414:[e-mail]::vc2yo3hvv+h7+NNF:a8Ne
Date: Tue, 14 Apr 2009 02:19:35 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 13 Apr 2009 18:47:45 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, Apr 13, 2009 at 06:07:21PM -0500, Nicolas Williams wrote:
>> You're conflating unrelated things.  That you want to use the
>> authenticated client ID from a lower layer has nothing to do with
>> channel binding.  EXTERNAL does NOT do channel binding in the RFC5056
>> sense or any other sense for that matter.
>
> I should preempt your response: the channel binding cannot help the
> mechanism (in this case EXTERNAL) find the authenticated ID of the
> corresponding channel.  Consider an implementation where TLS is being
> done in a different process than the one where SASL is being done: how
> does knowledge of the channel binding help the SASL mech find the
> channel?
>
> For EXTERNAL the app will just have to retrieve the authenticated ID
> itself.

The name of the channel will help, though.  Then the app will know to
use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS
etc.

I'm not certain the channel binding documents is useful here though, it
will require implementers to understand all channel bindings available
for, e.g., TLS.  It may be simpler to do EXTERNAL-* directly.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E0EgCR071728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 17:14:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3E0Egwp071727; Mon, 13 Apr 2009 17:14:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3E0EeXR071720 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Apr 2009 17:14:41 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtWIQ-0005Us-Ky; Tue, 14 Apr 2009 02:14:39 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090413:[e-mail]::wIF7RqwOrJjT4AvB:2ACs
X-Hashcash: 1:22:090413:[e-mail]::cJfZfCp3HdPu3gZA:ZEB7
Date: Tue, 14 Apr 2009 02:14:37 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Mon, 13 Apr 2009 23:39:56 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> GS2 SASL mechanism names must be 20 characters (after removing “GS2-“ 
> prefix and “–PLUS” suffix). The following text in Section 3.3 is out
> of date:
>
> The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
> 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
> 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
> 93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
> binary, and re-group them in groups of 5, and convert them back to
> decimal, which results in these computations:
>
> It should say instead “the first 7 octets, drop 1 bit”.

Thanks, fixed.

> In Section 4.1:
>
> Also, the server SHOULD refrain from sending GSS-API error tokens
> (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
> along with a major status code other than GSS_S_COMPLETE or
> GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>
> I am not sure I agree – SASL error reporting is poor.

Are you asking for GSS-API error tokens to be sent?

I agree with you that SASL error reporting is poor, but I'm not sure
sending GSS-API error tokens will help -- the problem is typically the
APIs between the SASL library and the application.  Also, GSS-API error
reporting is also generally poor (e.g., no localization).

> Later in the same section:
>
> gs2-std-mech = "F"
> ;; "F" means the mechanism is NOT is a
> Extra “is”
> ;; standard GSS-API mechanism in that the
> ;; RFC2743 section 3.1 header was missing

Fixed, thanks.

> The server MUST replace any occurance of "=" (comma) in the string
>
> s/(comma)/(equal sign)
>
> with "=3D".

I used 'equals' instead, as per RFC 20.

> Should the document require application of SASLPrep to authorization
> identity? I think it should, or SCRAM is not going to match GS2.
> If SASLPrep is to be used, then SASLPrep errors should also be listed
> in Section 7.

SASLPrep of authorization identities is an application issue, not a SASL
mechanism issue.  As such, SCRAM should not perform SASLprep of
authzid's.

> In Section 5:
>
> If the server supports channel binding then it must list both forms
>
> s/must/MUST
>
> of the SASL mechanism name for each GSS-API mechanism supported via
> GS2 (i.e., GSS-API mechanisms that support channel binding).

Done.

> Example #4: using channel binding.
>
> C: Request authentication exchange
> S: Empty Challenge
> C: yauthzid=someuser, <initial context token with standard
>
> Should this start with “p”?
>
> header removed>
> S: Send reply context token as is

Yes.

> 10.  GSS_Mechanism_SASLname call
>
>   To allow SASL implementations to query for the SASL mechanism name of
>   a GSS-API mechanism, we specify a new GSS-API function for this
>   purpose.
>
>      Inputs:
>
>      o desired_mech OBJECT IDENTIFIER
>
>      Outputs:
>
>      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>        (really, ASCII)
>
>      o mech_name UTF-8 STRING -- name of this mechanism, possibly
>        localized
>
>      o mech_description UTF-8 STRING -- possibly localized
>        description of this mechanism.
>
>
> With my Apps AD hat on: if you want to allow localization, you need a
> way to control language/local. So a new parameter for language tags is
> needed (see RFC 4646).

I removed the part about localization.  Frankly, I'm not sure the
'mech_name' and 'mech_description' fields are useful.  The important
part is the 'sasl_mech_name' field.

> In Section 14.3:
>
> GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
> with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
> be used as a GS2 mechanism. To make this easier for SASL
> implementations we assign a symbolic SASL mechanism name to the
> SPNEGO GSS-API mechanism: "SPNEGO".
>
> If SPNEGO is disallowed in GS2, why do we assign a name to it?

Presumably in case SPNEGO is going to be used in SASL:

		    [What about SASL apps that don't do mechanism
		    negotiation?  Probably none exist.  But if any did
		    then presumably it would OK to use the SPNEGO
		    mechanism, no?  -Nico]</t>

However, I'm also a bit skeptical about assigning a name for it.

> The channel binding data MAY be sent (byt the actual GSS-API
>
> Typo: by
>
> mechanism used) without confidentiality protection and knowledge of
> it is assumed to provide no advantage to an MITM (who can, in any
> case, compute the channel binding data independently). If the
> external channel does not provide confidentiality protection and the
> GSS-API mechanism does not provide confidentiality protection for the
> channel binding data, then passive attackers (eavesdroppers) can
> recover the channel binding data. See [RFC5056].
>
> […]
>
> GS2 does not directly use any cryptographic algorithms, therefore it
> is automatically "algorithm agile", or, as agile as the GSS-API
> mechanisms that are available for use in SASL apoplications via GS2.
>
> Typo: applications

Thanks.

Updated document:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt

Changes compared to -11:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html

Please verify that your suggestions have been fixed.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNvASJ070521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 16:57:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DNvAQR070520; Mon, 13 Apr 2009 16:57:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNv9wC070514 for <[e-mail]>; Mon, 13 Apr 2009 16:57:09 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3DNv9it017819 for <[e-mail]>; Mon, 13 Apr 2009 23:57: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 n3DNv9UQ025109 for <[e-mail]>; Mon, 13 Apr 2009 17:57:09 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3DNljZn010318; Mon, 13 Apr 2009 18:47:45 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3DNljGD010317; Mon, 13 Apr 2009 18:47:45 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 13 Apr 2009 18:47:45 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 13, 2009 at 06:07:21PM -0500, Nicolas Williams wrote:
> You're conflating unrelated things.  That you want to use the
> authenticated client ID from a lower layer has nothing to do with
> channel binding.  EXTERNAL does NOT do channel binding in the RFC5056
> sense or any other sense for that matter.

I should preempt your response: the channel binding cannot help the
mechanism (in this case EXTERNAL) find the authenticated ID of the
corresponding channel.  Consider an implementation where TLS is being
done in a different process than the one where SASL is being done: how
does knowledge of the channel binding help the SASL mech find the
channel?

For EXTERNAL the app will just have to retrieve the authenticated ID
itself.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNqWBX070286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 16:52:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DNqWsc070285; Mon, 13 Apr 2009 16:52: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-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNqUic070278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Apr 2009 16:52:31 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtVwy-0005Uf-PQ for [e-mail]; Tue, 14 Apr 2009 01:52:29 +0200
X-Hashcash: 1:22:090413:[e-mail]::BMxA7QuX4lgAJb6M:BxpX
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: draft-josefsson-sasl-external-channel-01
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090413:[e-mail]::Soov5haMMRcvNe+x:0asN
X-Hashcash: 1:22:090413:[e-mail]::21gJ0X7fuIchJO6K:0/tj
Date: Tue, 14 Apr 2009 01:52:27 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Mon, 13 Apr 2009 16:45:01 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I've noticed some renewed interest in an EXTERNAL variant that refers to
an outer TLS channel, so I updated my earlier EXTERNAL-CHANNEL document.

There is one open issue: whether it is worthwhile to reference RFC 5056
for channel names, or whether the document should go ahead and define a
EXTERNAL-TLS mechanism directly.  That would refer directly to an outer
TLS channel.  It could also reserve EXTERNAL-* for other external
security channels.  I don't care strongly, but I do suspect that
interoperability will be better with the EXTERNAL-TLS approach (as there
are multiple channel names for TLS channels already, and more are
proposed).

/Simon

[e-mail] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism for External Authentication using a Named Channel: EXTERNAL-CHANNEL
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-01.txt
> 	Pages           : 9
> 	Date            : 2009-04-13
>
> This document describes a way to perform end-user authentication in
> the Simple Authentication and Security Layer (SASL) framework by re-
> using an external security layer (such as the Transport Layer
> Security (TLS) protocol) that may have already completed end-user
> authentication.  In comparison with the existing EXTERNAL mechanism,
> this mechanism alleviates the a priori assumptions made by the design
> of the EXTERNAL mechanism.  This mechanism transfers an identifier of
> the external channel to be used explicitly.
>
> See <http://josefsson.org/external-channel/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNGus0068400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 16:16:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DNGubG068399; Mon, 13 Apr 2009 16:16: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-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNGjIA068380 for <[e-mail]>; Mon, 13 Apr 2009 16:16:55 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3DNGitC006828 for <[e-mail]>; Mon, 13 Apr 2009 23:16:45 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3DNGiNB005997 for <[e-mail]>; Mon, 13 Apr 2009 17:16:44 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3DN7LWf010288; Mon, 13 Apr 2009 18:07:21 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3DN7Lde010287; Mon, 13 Apr 2009 18:07:21 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 13 Apr 2009 18:07:21 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 13, 2009 at 03:55:53PM -0700, Kurt Zeilenga wrote:
> >Can you elaborate?  Also, EXTERNAL is just not an issue.
> 
> Basically, there is a desire for a client to state from which lower- 
> level it wishes to pull up an identity from.  So, my idea is to use  
> unique channel bindings to specify which lower-level.  This use of  
> channel binding is not intended to add any security protection, just  
> as a convenient means to uniquely identify a channel.

You're conflating unrelated things.  That you want to use the
authenticated client ID from a lower layer has nothing to do with
channel binding.  EXTERNAL does NOT do channel binding in the RFC5056
sense or any other sense for that matter.

YAP is interesting though: it depends on using a unique channel binding
rather than an end-point channel binding because it uses the unique
channel binding as a nonce.

So I see your point w.r.t. YAP.

I think what we can do then is this: the application MUST provide all
the types of channel binding available and the mechanism MUST pick one
to use according to the default rules we shall list (prefer
tls-server-end-point over tls-unique) or one specified for the mechanism
(YAP always insists on tls-unique).

That's more complex than I'd prefer.  I don't mind the alternatives
though: either forget YAP or use of YAP will require YAP-specific logic
in the application.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNFwlm068346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 16:15:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DNFwS1068345; Mon, 13 Apr 2009 16:15:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DNFjrj068330 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Apr 2009 16:15:57 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LtVNO-0005UN-Gc; Tue, 14 Apr 2009 01:15:43 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090413:[e-mail]::r/5Pvr3L+5Mk0Umd:8f10
X-Hashcash: 1:22:090413:[e-mail]::6heGH/7MP1qoQaUC:AnZU
X-Hashcash: 1:22:090413:[e-mail]::+XJMvr7He12FBddw:If8d
Date: Tue, 14 Apr 2009 01:15:41 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Mon, 13 Apr 2009 15:55:53 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Apr 13, 2009, at 2:19 PM, Nicolas Williams wrote:
>
>>
>> On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
>>> I generally do not favor changing RFC 4422 as discussed in this I-D.
>>>
>>> My view is that while GS2 mechanisms (such as SCRAM) handle channel
>>> in
>>> similar ways (by design), we should not impose any restriction that
>>> other mechanisms which support channel bindings do so in a like way.
>>>
>>> For instance, many of the suggested restrictions make little sense
>>> for
>>> YAP.  Nor would they necessarily make sense for a "channel-bound"
>>> EXTERNAL mechanism (which, BTW, I have in the works).
>>
>> Can you elaborate?  Also, EXTERNAL is just not an issue.
>
> Basically, there is a desire for a client to state from which lower-
> level it wishes to pull up an identity from.  So, my idea is to use
> unique channel bindings to specify which lower-level.  This use of
> channel binding is not intended to add any security protection, just
> as a convenient means to uniquely identify a channel.

That is already described in:

http://tools.ietf.org/html/draft-josefsson-sasl-external-channel-00

There were comments that said transferring the actual channel binding
data is pointless, so I'll remove that part and resubmit as -01.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DMtxn8066672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 15:56:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DMtx1E066671; Mon, 13 Apr 2009 15:55:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DMtwl9066663 for <[e-mail]>; Mon, 13 Apr 2009 15:55:58 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.181] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SePC=AB=[e-mail]>; Mon, 13 Apr 2009 23:55:57 +0100
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 15:55:53 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Apr 13, 2009, at 2:19 PM, Nicolas Williams wrote:

>
> On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
>> I generally do not favor changing RFC 4422 as discussed in this I-D.
>>
>> My view is that while GS2 mechanisms (such as SCRAM) handle channel  
>> in
>> similar ways (by design), we should not impose any restriction that
>> other mechanisms which support channel bindings do so in a like way.
>>
>> For instance, many of the suggested restrictions make little sense  
>> for
>> YAP.  Nor would they necessarily make sense for a "channel-bound"
>> EXTERNAL mechanism (which, BTW, I have in the works).
>
> Can you elaborate?  Also, EXTERNAL is just not an issue.

Basically, there is a desire for a client to state from which lower- 
level it wishes to pull up an identity from.  So, my idea is to use  
unique channel bindings to specify which lower-level.  This use of  
channel binding is not intended to add any security protection, just  
as a convenient means to uniquely identify a channel.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DMenR2066124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 15:40:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DMenoF066123; Mon, 13 Apr 2009 15:40:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DMemeV066117 for <[e-mail]>; Mon, 13 Apr 2009 15:40:49 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.148.108] (92.40.148.108.sub.mbb.three.co.uk [92.40.148.108])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SeO=bgB=[e-mail]>; Mon, 13 Apr 2009 23:40:47 +0100
Message-ID: <[e-mail]>
Date: Mon, 13 Apr 2009 23:39:56 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: SASL WG <[e-mail]>
Subject: Comments on draft-ietf-sasl-gs2-11.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

GS2 SASL mechanism names must be 20 characters (after removing =93GS2-=93=20
prefix and =93=96PLUS=94 suffix). The following text in Section 3.3 is out o=
f=20
date:

The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
binary, and re-group them in groups of 5, and convert them back to
decimal, which results in these computations:

It should say instead =93the first 7 octets, drop 1 bit=94.

In Section 4.1:

Also, the server SHOULD refrain from sending GSS-API error tokens
(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
along with a major status code other than GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.

I am not sure I agree =96 SASL error reporting is poor.

Later in the same section:

gs2-std-mech =3D "F"
;; "F" means the mechanism is NOT is a
Extra =93is=94
;; standard GSS-API mechanism in that the
;; RFC2743 section 3.1 header was missing


The server MUST replace any occurance of "=3D" (comma) in the string

s/(comma)/(equal sign)

with "=3D3D".


Should the document require application of SASLPrep to authorization=20
identity? I think it should, or SCRAM is not going to match GS2.
If SASLPrep is to be used, then SASLPrep errors should also be listed in=20
Section 7.


In Section 5:

If the server supports channel binding then it must list both forms

s/must/MUST

of the SASL mechanism name for each GSS-API mechanism supported via
GS2 (i.e., GSS-API mechanisms that support channel binding).


Example #4: using channel binding.

C: Request authentication exchange
S: Empty Challenge
C: yauthzid=3Dsomeuser, <initial context token with standard

Should this start with =93p=94?

header removed>
S: Send reply context token as is


10.  GSS_Mechanism_SASLname call

   To allow SASL implementations to query for the SASL mechanism name of
   a GSS-API mechanism, we specify a new GSS-API function for this
   purpose.

      Inputs:

      o desired_mech OBJECT IDENTIFIER

      Outputs:

      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
        (really, ASCII)

      o mech_name UTF-8 STRING -- name of this mechanism, possibly
        localized

      o mech_description UTF-8 STRING -- possibly localized
        description of this mechanism.


With my Apps AD hat on: if you want to allow localization, you need a=20
way to control language/local. So a new parameter for language tags is=20
needed (see RFC 4646).


In Section 14.3:

GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
be used as a GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name to the
SPNEGO GSS-API mechanism: "SPNEGO".

If SPNEGO is disallowed in GS2, why do we assign a name to it?


The channel binding data MAY be sent (byt the actual GSS-API

Typo: by

mechanism used) without confidentiality protection and knowledge of
it is assumed to provide no advantage to an MITM (who can, in any
case, compute the channel binding data independently). If the
external channel does not provide confidentiality protection and the
GSS-API mechanism does not provide confidentiality protection for the
channel binding data, then passive attackers (eavesdroppers) can
recover the channel binding data. See [RFC5056].

[=85]

GS2 does not directly use any cryptographic algorithms, therefore it
is automatically "algorithm agile", or, as agile as the GSS-API
mechanisms that are available for use in SASL apoplications via GS2.

Typo: applications



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DLT8Li062316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 14:29:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DLT8ng062315; Mon, 13 Apr 2009 14:29: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.14.2/8.14.2) with ESMTP id n3DLSrNT062305 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 13 Apr 2009 14:29:03 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3DLSoo1012441 for <[e-mail]>; Mon, 13 Apr 2009 21:28:52 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 n3DLSoap046721 for <[e-mail]>; Mon, 13 Apr 2009 15:28:50 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3DLJRVa010128; Mon, 13 Apr 2009 16:19:27 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3DLJOxY010127; Mon, 13 Apr 2009 16:19:24 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 13 Apr 2009 16:19:24 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
> I generally do not favor changing RFC 4422 as discussed in this I-D.
> 
> My view is that while GS2 mechanisms (such as SCRAM) handle channel in  
> similar ways (by design), we should not impose any restriction that  
> other mechanisms which support channel bindings do so in a like way.
> 
> For instance, many of the suggested restrictions make little sense for  
> YAP.  Nor would they necessarily make sense for a "channel-bound"  
> EXTERNAL mechanism (which, BTW, I have in the works).

Can you elaborate?  Also, EXTERNAL is just not an issue.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DL47BF060919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 14:04:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3DL47a7060918; Mon, 13 Apr 2009 14:04:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3DL3tb1060900 for <[e-mail]>; Mon, 13 Apr 2009 14:04:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.181] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SeOotwB=[e-mail]> for <[e-mail]>; Mon, 13 Apr 2009 22:03:52 +0100
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt 
Date: Mon, 13 Apr 2009 14:03:47 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I generally do not favor changing RFC 4422 as discussed in this I-D.

My view is that while GS2 mechanisms (such as SCRAM) handle channel in  
similar ways (by design), we should not impose any restriction that  
other mechanisms which support channel bindings do so in a like way.

For instance, many of the suggested restrictions make little sense for  
YAP.  Nor would they necessarily make sense for a "channel-bound"  
EXTERNAL mechanism (which, BTW, I have in the works).

-- Kurt

On Apr 9, 2009, at 4:15 PM, [e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Simple Authentication and Security  
> Layer Working Group of the IETF.
>
>
> 	Title           : SASL And Channel Binding
> 	Author(s)       : N. Williams
> 	Filename        : draft-ietf-sasl-channel-bindings-00.txt
> 	Pages           : 8
> 	Date            : 2009-04-09
>
> This document specifies the semantics of channel binding for the
> Simple Authentication and Security Layers (SASL) framework,
> mechanisms and applications.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <mime-attachment>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AMNgje041025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 15:23:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3AMNgCP041024; Fri, 10 Apr 2009 15:23:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AMNWQY041014 for <[e-mail]>; Fri, 10 Apr 2009 15:23:42 -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 n3AMNVq5019320 for <[e-mail]>; Fri, 10 Apr 2009 22:23:32 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 n3AMNVP9022442 for <[e-mail]>; Fri, 10 Apr 2009 16:23:31 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3AM6d2q008558; Fri, 10 Apr 2009 17:06:39 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3AM6dcM008557; Fri, 10 Apr 2009 17:06:39 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 10 Apr 2009 17:06:39 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Optimizing use of SASL/GS2 over TLS
Message-ID: <[e-mail]>
Reply-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>

[Note: SASL and KITTEN WGs are Bcc'ed.]

I've submitted an I-D describing how to reduce the number of round trips
needed for SASL/GS2 mechanism negotiation and authentication when
running over TLS:

    draft-williams-tls-app-sasl-opt-01.txt

This can be seen as a variant of the TLS/GSS proposal from a while back
as it achieves the same result: you can use the GSS-API for
authentication _and_ TLS for session protection without having to pay a
round trip penalty.  But it does it in a slightly different and simpler
way.

I'm hoping this proposal will be less controversial than the TLS/GSS
proposal.

Comments?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AITIhm026982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 11:29:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3AITImN026981; Fri, 10 Apr 2009 11:29:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3AIT7Hd026968 for <[e-mail]>; Fri, 10 Apr 2009 11:29:17 -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 n3AIT6sS001462 for <[e-mail]>; Fri, 10 Apr 2009 18:29:07 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3AIT6kj003655 for <[e-mail]>; Fri, 10 Apr 2009 12:29:06 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3AIJgYN008376 for <[e-mail]>; Fri, 10 Apr 2009 13:19:42 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3AIJgN0008375 for [e-mail]; Fri, 10 Apr 2009 13:19:42 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 10 Apr 2009 13:19:42 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Never mind (Re: Protecting the mech negotiation in GS2)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Never mind -- if one is doing channel binding (and one should be) then
the mechanism negotiation is protected implicitly.  And if not, well,
since the new mechanisms don't have sec layers there's not much point in
protecting the negotiation.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39NGAKm052744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 16:16:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n39NGAYO052743; Thu, 9 Apr 2009 16:16:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39NGAM1052737 for <[e-mail]>; Thu, 9 Apr 2009 16:16:10 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 75B6E3A6AEF; Thu,  9 Apr 2009 16:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  9 Apr 2009 16:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-00.txt
	Pages           : 8
	Date            : 2009-04-09

This document specifies the semantics of channel binding for the
Simple Authentication and Security Layers (SASL) framework,
mechanisms and applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-00.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-channel-bindings-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39N4QXZ052041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 16:04:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n39N4QS9052040; Thu, 9 Apr 2009 16:04: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-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39N4F7b052027 for <[e-mail]>; Thu, 9 Apr 2009 16:04:25 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n39N4ElY013572 for <[e-mail]>; Thu, 9 Apr 2009 23:04:14 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 n39N4EVT008481 for <[e-mail]>; Thu, 9 Apr 2009 17:04:14 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n39MsqWf007729 for <[e-mail]>; Thu, 9 Apr 2009 17:54:52 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n39MsosJ007728 for [e-mail]; Thu, 9 Apr 2009 17:54:50 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 9 Apr 2009 17:54:50 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Updating RFC4422 to support channel bindings
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've submitted draft-ietf-sasl-channel-bindings-00.txt to update RFC4422
to support channel bindings.

I expect that the chairs will want to approve of this initial
submission.

Until then you can find the submitted I-D at:

http://www.ietf.org/proceedings/staging/draft-ietf-sasl-channel-bindings-00.txt

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39GYhtv030069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 09:34:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n39GYh4c030068; Thu, 9 Apr 2009 09:34:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n39GYWRX030054 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 9 Apr 2009 09:34:43 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n39GYWnW028251 for <[e-mail]>; Thu, 9 Apr 2009 16:34: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 n39GYVYb051276 for <[e-mail]>; Thu, 9 Apr 2009 10:34:31 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n39GP9QF007360 for <[e-mail]>; Thu, 9 Apr 2009 11:25:09 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n39GP9Kn007359 for [e-mail]; Thu, 9 Apr 2009 11:25:09 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 9 Apr 2009 11:25:09 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Protecting the mech negotiation in GS2
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I proposed a while back that we could protect the server's mech list in
GS2.  That saves a round-trip for applications that want to protect the
mechanism negotiation.  As such it seems worth doing, and the change for
it is very small:

a) add a flag to the GS2 initial auth message header indicating whether
   the server mech list is being protected, and

b) add the server mech list to the GS2 channel binding data header.

The impact on SASL APIs should be none beyond the impact of channel
binding and the negotiation of channel binding in the first place.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33K0tsZ013836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 13:00:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33K0tJT013835; Fri, 3 Apr 2009 13:00:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33K0hFm013813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 3 Apr 2009 13:00:54 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n33K0dfA013008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 16:00:40 -0400 (EDT)
Date: Fri, 03 Apr 2009 16:00:39 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>
cc: Dave Cridland <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, April 03, 2009 02:19:56 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

>> Except I think that's the wrong way; the server must fail authentication
>> if  it advertised channel bindings and the client reports that it did
>> not see  such an advertisement.
>
> It's worse than that -- GS2 always uses GSS channel bindings, so that
> semantic from MIT krb5 wouldn't help anyways.

I think you misinterpreted.  Let me try again.

If the server advertised support for -PLUS, indicating that it could do CB, 
but the client reports that it saw no such advertisement, then that 
indicates an attacker modified the advertisement en route, and the server 
MUST fail authentication at the SASL layer.  This happens without ever 
calling GSS.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33JiReG013159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 12:44:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33JiR9p013158; Fri, 3 Apr 2009 12:44:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33JiGpS013139 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 3 Apr 2009 12:44:26 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n33JiFV4014298 for <[e-mail]>; Fri, 3 Apr 2009 19:44:15 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 n33JiFFj057641 for <[e-mail]>; Fri, 3 Apr 2009 13:44:15 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33JJvPm003110; Fri, 3 Apr 2009 14:19:57 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33JJuEr003109; Fri, 3 Apr 2009 14:19:56 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 14:19:56 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Dave Cridland <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 02:19:49PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, April 03, 2009 12:28:58 PM -0500 Nicolas Williams 
> <[e-mail]> wrote:
> >I wasn't proposing that.  Instead I was proposing that in the case where
> >the client did not negotiate mechanisms but used channel binding and the
> >server couldn't, then the server could ignore those channel bindings IFF
> >the client used a non-PLUS mechanism name.  (In GSS terms the SCRAM GSS
> >mech's GSS_Accept_sec_context() with GSS_C_NO_CHANNEL_BINDINGS would
> >ignore the client's channel bindings, just like the MIT krb5 mech
> >implementation used to, but GS2 would protect against downgrade by
> >protecting the SASL mechname used by the client and failing
> >authentication if the client used the -PLUS name and the server had no
> >channel bindings.)
> 
> Except I think that's the wrong way; the server must fail authentication if 
> it advertised channel bindings and the client reports that it did not see 
> such an advertisement.

It's worse than that -- GS2 always uses GSS channel bindings, so that
semantic from MIT krb5 wouldn't help anyways.

> The only possible reason to do what you describe is to allow a server to 
> advertise -plus, but defer the determination as to whether it supports CB 
> until after the client sends them.  That's fine, but not if the decision is 
> made based on the type of CB the client sent, which is what you'd need for 
> negotiation but breaks the protocol.

Right, forget all about this.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33IJsZ9009183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 11:19:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33IJs4b009182; Fri, 3 Apr 2009 11:19:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33IJqts009176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 3 Apr 2009 11:19:53 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n33IJntw009690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 14:19:49 -0400 (EDT)
Date: Fri, 03 Apr 2009 14:19:49 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>
cc: Dave Cridland <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, April 03, 2009 12:28:58 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

> On Fri, Apr 03, 2009 at 01:26:50PM -0400, Jeffrey Hutzelman wrote:
>> --On Friday, April 03, 2009 11:58:20 AM -0500 Nicolas Williams
>> <[e-mail]> wrote:
>>
>> > On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
>> >> We had an agreement before San Franscisco as to how CB negotation
>> >> should work.  I carefuly analyzed that approach to be sure that it
>> >> works correctly, allows CB to be used when possible, allows
>> >> interoperability when CB cannot be used, and prevents downgrade
>> >> attacks.
>> >>
>> >> I lack the time to think about whether what you just described is
>> >> semantically equivalent to the previous agreement and whether it still
>> >> meets the requirements and remains secure.
>> >>
>> >> Can we _please_ stop changing this?
>> >
>> > In this particular case I think so, because Dave's concern can be
>> > addressed differently by saying "don't do that", where "that" ->
>> > code/configure your server to advertise -PLUS and then not be able to
>> > use the required channel binding type for the given situation.
>>
>> In fact, that is the only thing you can do.
>> You can't give the server license to ignore the client's channel
>> bindings  if they're the wrong type, because that enables a MitM attack
>> where the  attackers channels from the client and to the server are of
>> different types.
>
> I wasn't proposing that.  Instead I was proposing that in the case where
> the client did not negotiate mechanisms but used channel binding and the
> server couldn't, then the server could ignore those channel bindings IFF
> the client used a non-PLUS mechanism name.  (In GSS terms the SCRAM GSS
> mech's GSS_Accept_sec_context() with GSS_C_NO_CHANNEL_BINDINGS would
> ignore the client's channel bindings, just like the MIT krb5 mech
> implementation used to, but GS2 would protect against downgrade by
> protecting the SASL mechname used by the client and failing
> authentication if the client used the -PLUS name and the server had no
> channel bindings.)

Except I think that's the wrong way; the server must fail authentication if 
it advertised channel bindings and the client reports that it did not see 
such an advertisement.

There are only three cases:

- client saw advertisement and uses CB
- client saw advertisement and does not use CB
- client did not see advertisement

In the third case, if the server advertised CB at all it must fail.
In the first case, if the client's CB is the wrong type it must fail.

If the server could not use CB, it should not have advertised -plus.

The only possible reason to do what you describe is to allow a server to 
advertise -plus, but defer the determination as to whether it supports CB 
until after the client sends them.  That's fine, but not if the decision is 
made based on the type of CB the client sent, which is what you'd need for 
negotiation but breaks the protocol.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HrJbj007446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 10:53:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33HrJqP007445; Fri, 3 Apr 2009 10:53:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HrIgo007437 for <[e-mail]>; Fri, 3 Apr 2009 10:53:18 -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 n33HrIh1015618 for <[e-mail]>; Fri, 3 Apr 2009 17:53:18 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 n33HrHVN041385 for <[e-mail]>; Fri, 3 Apr 2009 11:53:17 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33HSwC7003023; Fri, 3 Apr 2009 12:28:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33HSwBl003022; Fri, 3 Apr 2009 12:28:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 12:28:58 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Dave Cridland <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 01:26:50PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, April 03, 2009 11:58:20 AM -0500 Nicolas Williams 
> <[e-mail]> wrote:
> 
> >On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
> >>We had an agreement before San Franscisco as to how CB negotation
> >>should work.  I carefuly analyzed that approach to be sure that it
> >>works correctly, allows CB to be used when possible, allows
> >>interoperability when CB cannot be used, and prevents downgrade
> >>attacks.
> >>
> >>I lack the time to think about whether what you just described is
> >>semantically equivalent to the previous agreement and whether it still
> >>meets the requirements and remains secure.
> >>
> >>Can we _please_ stop changing this?
> >
> >In this particular case I think so, because Dave's concern can be
> >addressed differently by saying "don't do that", where "that" ->
> >code/configure your server to advertise -PLUS and then not be able to
> >use the required channel binding type for the given situation.
> 
> In fact, that is the only thing you can do.
> You can't give the server license to ignore the client's channel bindings 
> if they're the wrong type, because that enables a MitM attack where the 
> attackers channels from the client and to the server are of different types.

I wasn't proposing that.  Instead I was proposing that in the case where
the client did not negotiate mechanisms but used channel binding and the
server couldn't, then the server could ignore those channel bindings IFF
the client used a non-PLUS mechanism name.  (In GSS terms the SCRAM GSS
mech's GSS_Accept_sec_context() with GSS_C_NO_CHANNEL_BINDINGS would
ignore the client's channel bindings, just like the MIT krb5 mech
implementation used to, but GS2 would protect against downgrade by
protecting the SASL mechname used by the client and failing
authentication if the client used the -PLUS name and the server had no
channel bindings.)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HQuP8005729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 10:26:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33HQumc005728; Fri, 3 Apr 2009 10:26:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HQsRS005720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 3 Apr 2009 10:26:55 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n33HQodw007598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 13:26:50 -0400 (EDT)
Date: Fri, 03 Apr 2009 13:26:50 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>
cc: Dave Cridland <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, April 03, 2009 11:58:20 AM -0500 Nicolas Williams 
<[e-mail]> wrote:

> On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
>> We had an agreement before San Franscisco as to how CB negotation
>> should work.  I carefuly analyzed that approach to be sure that it
>> works correctly, allows CB to be used when possible, allows
>> interoperability when CB cannot be used, and prevents downgrade
>> attacks.
>>
>> I lack the time to think about whether what you just described is
>> semantically equivalent to the previous agreement and whether it still
>> meets the requirements and remains secure.
>>
>> Can we _please_ stop changing this?
>
> In this particular case I think so, because Dave's concern can be
> addressed differently by saying "don't do that", where "that" ->
> code/configure your server to advertise -PLUS and then not be able to
> use the required channel binding type for the given situation.

In fact, that is the only thing you can do.
You can't give the server license to ignore the client's channel bindings 
if they're the wrong type, because that enables a MitM attack where the 
attackers channels from the client and to the server are of different types.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HMpsQ005519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 10:22:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33HMpew005518; Fri, 3 Apr 2009 10:22:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HMev0005506 for <[e-mail]>; Fri, 3 Apr 2009 10:22:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33HMdQb019182 for <[e-mail]>; Fri, 3 Apr 2009 17:22:40 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 n33HMdjX017761 for <[e-mail]>; Fri, 3 Apr 2009 11:22:39 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33GwKNO002970; Fri, 3 Apr 2009 11:58:20 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33GwKeQ002969; Fri, 3 Apr 2009 11:58:20 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 11:58:20 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Dave Cridland <[e-mail]>, Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
> We had an agreement before San Franscisco as to how CB negotation
> should work.  I carefuly analyzed that approach to be sure that it
> works correctly, allows CB to be used when possible, allows
> interoperability when CB cannot be used, and prevents downgrade
> attacks.
> 
> I lack the time to think about whether what you just described is
> semantically equivalent to the previous agreement and whether it still
> meets the requirements and remains secure.
> 
> Can we _please_ stop changing this?

In this particular case I think so, because Dave's concern can be
addressed differently by saying "don't do that", where "that" ->
code/configure your server to advertise -PLUS and then not be able to
use the required channel binding type for the given situation.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HJRk7005282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 10:19:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33HJQe2005281; Fri, 3 Apr 2009 10:19: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-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33HJQfI005275 for <[e-mail]>; Fri, 3 Apr 2009 10:19:26 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33HJQlH010183 for <[e-mail]>; Fri, 3 Apr 2009 17:19:26 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 n33HJPe6047472 for <[e-mail]>; Fri, 3 Apr 2009 11:19:25 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33Gt7eH002962; Fri, 3 Apr 2009 11:55:07 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33Gt6aY002961; Fri, 3 Apr 2009 11:55:06 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 11:55:06 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 12:05:29PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, April 03, 2009 12:21:56 PM +0200 Simon Josefsson 
> <[e-mail]> wrote:
> 
> >>The idea is that when the TLS channel used server certs then the client
> >>MUST use tls-server-end-point bindings.  Otherwise it MUST use
> >>tls-unique bindings.
> >
> >Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.
> 
> It doesn't belong in either.

I agree.  We need to update RFC4422 to specify the channel binding
semantics of SASL, the -PLUS thing, and the rules for selecting TLS
channel binding types.

(I also knew we'd have to do that eventually, but wanted to wait until
the dust settled on SCRAM/GS2 -- which has happened, pretty much -- to
bring that up.  It was important to settle these matters in the context
of SCRAM/GS2 _first_, but it is also important to document these in the
context of an update to SASL.)

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33H8Xd5004474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 10:08:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33H8X5E004473; Fri, 3 Apr 2009 10:08:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33H8VXe004465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 3 Apr 2009 10:08:32 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n33H8VhG000282 for <[e-mail]>; Fri, 3 Apr 2009 17:08:31 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33H8U4J038026 for <[e-mail]>; Fri, 3 Apr 2009 11:08:30 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33GiBoj002950; Fri, 3 Apr 2009 11:44:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33GiBRf002949; Fri, 3 Apr 2009 11:44:11 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 11:44:11 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: Mark Novak <[e-mail]>, [e-mail], Stefan Santesson <[e-mail]>, Larry Zhu <[e-mail]>, [e-mail], Paul Leach <[e-mail]>, Kevin Damour <[e-mail]>, Jeffrey Altman <[e-mail]>, Sam Hartman <[e-mail]>
Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <15429.1238776301.804018@puncture>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15429.1238776301.804018@puncture>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 05:31:41PM +0100, Dave Cridland wrote:
> On Fri Apr  3 16:25:36 2009, Nicolas Williams wrote:
> >  I
> >don't know though.  Can you comment on Pasi's comments?  Are there  
> >any
> >commonly used TLS implementations that encode the server cert
> >differently on the wire than in their APIs for getting at the server
> >cert?
> 
> I have no idea at all, I'm sorry to say. It makes sense to me that  
> X.509 certs, at least, would always be encoded in DER, since that's  
> the form in which they're signed.

Between this and my other comment I'm willing to close this as a
non-issue.

> That then reduces the problem of the existing channel binding to  
> being figuring out which hash to use, and I strongly suspect that  
> just using SHA-256 is sufficient for now. (it's unfortunate this is  
> different to the hash algorithm we seem to have settled on for SCRAM,  
> but it's far from a blocker, merely a mild inconvenience).

Right, we chose SHA-256 for tls-server-end-point because it should
future proof us for long enough that people will be able to implement a
cert->hash API as described in tls-server-end-point.  I think that's
fine.  We couldn't use SHA-1 because we're not using HMAC here, so
there's no mitigation against SHA-1 breaks.  SHA-256 implementations,
including open source ones in various licenses, exist.  So I'm going to
consider this a non-issue also.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33GVxCA002019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 09:31:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33GVxZC002018; Fri, 3 Apr 2009 09:31:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33GVvSB002011 for <[e-mail]>; Fri, 3 Apr 2009 09:31:58 -0700 (MST) (envelope-from [e-mail])
Received: from puncture (turner.dave.cridland.net [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Fri, 3 Apr 2009 17:31:54 +0100
Subject: Re: TLS endpoint channel bindings in SCRAM
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <15429.1238776301.804018@puncture>
Date: Fri, 03 Apr 2009 17:31:41 +0100
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, Mark Novak <[e-mail]>, Larry Zhu <[e-mail]>, Sam Hartman <[e-mail]>, Leif Johansson <[e-mail]>, Paul Leach <[e-mail]>, Jeffrey Altman <[e-mail]>, Kevin Damour <[e-mail]>, Stefan Santesson <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri Apr  3 16:25:36 2009, Nicolas Williams wrote:
> Pasi's comment indicates that your premise for this thread is wrong.

I certainly hope so. Nothing would please me more than being wrong  
here.

>   I
> don't know though.  Can you comment on Pasi's comments?  Are there  
> any
> commonly used TLS implementations that encode the server cert
> differently on the wire than in their APIs for getting at the server
> cert?

I have no idea at all, I'm sorry to say. It makes sense to me that  
X.509 certs, at least, would always be encoded in DER, since that's  
the form in which they're signed.

That then reduces the problem of the existing channel binding to  
being figuring out which hash to use, and I strongly suspect that  
just using SHA-256 is sufficient for now. (it's unfortunate this is  
different to the hash algorithm we seem to have settled on for SCRAM,  
but it's far from a blocker, merely a mild inconvenience).

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33G8dP9099706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 09:08:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33G8dSP099705; Fri, 3 Apr 2009 09:08:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33G8bJp099697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 3 Apr 2009 09:08:38 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n33G8YK0004450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 12:08:35 -0400 (EDT)
Date: Fri, 03 Apr 2009 12:08:34 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Dave Cridland <[e-mail]>
cc: Simon Josefsson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, April 03, 2009 10:10:25 AM -0500 Nicolas Williams 
<[e-mail]> wrote:

>
> On Fri, Apr 03, 2009 at 10:01:58AM -0500, Nicolas Williams wrote:
>> IF we're going to allow the server/acceptor-may-ignore-client-channel-
>> bindings-by-providing-none semantic then we must provide some indication
>> that this happened in the server's last message.  But because we need
>> this to be communicated to the client at the GS2 layer too, and securely
>> so, we'd be complicating GS2 significantly -- I don't think we want
>> that.
>
> Actually, there's a simple way to make that possible: put the mechanism
> name in the GS2 channel binding data header.  If the name ends in -PLUS
> then the server can't ignore the channel bindings because it must have
> advertised that it supports them.  Whereas if the name does not end in
> -PLUS then the server is free to ignore the client's channel bindings.
>
> Comments?

We had an agreement before San Franscisco as to how CB negotation should 
work.  I carefuly analyzed that approach to be sure that it works 
correctly, allows CB to be used when possible, allows interoperability when 
CB cannot be used, and prevents downgrade attacks.

I lack the time to think about whether what you just described is 
semantically equivalent to the previous agreement and whether it still 
meets the requirements and remains secure.

Can we _please_ stop changing this?

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33G5jEi099458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 09:05:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33G5jXk099457; Fri, 3 Apr 2009 09:05:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33G5X5Q099413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 3 Apr 2009 09:05:44 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n33G5T44004370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 12:05:29 -0400 (EDT)
Date: Fri, 03 Apr 2009 12:05:29 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Dave Cridland <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, April 03, 2009 12:21:56 PM +0200 Simon Josefsson 
<[e-mail]> wrote:

>> The idea is that when the TLS channel used server certs then the client
>> MUST use tls-server-end-point bindings.  Otherwise it MUST use
>> tls-unique bindings.
>
> Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.

It doesn't belong in either.
SCRAM and GS2 are SASL mechanisms; they operate below the SASL abstraction. 
Their job is to convey and verify the channel bindings provided by the 
application protocol.  They don't get to specify what channel bindings are 
used.  This is very important.

Whether to use channel bindings and which bindings to use is determined by 
the protocol operating above the SASL abstraction.  We can perhaps develop 
guidelines for how such protocols should behave, but they don't belong in a 
mechanism document.

Remember, the point of the abstraction is that individual users of SASL do 
not need to know about or understand individual mechanisms.  This breaks if 
there is any mechanism that attempts to apply mechanism-specific 
requirements to the protocol operating above the abstraction.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FnvHl098205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 08:49:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33Fnuph098204; Fri, 3 Apr 2009 08:49: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-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FnuYX098197 for <[e-mail]>; Fri, 3 Apr 2009 08:49:56 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33FntRw022609 for <[e-mail]>; Fri, 3 Apr 2009 15:49:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33FntFZ033336 for <[e-mail]>; Fri, 3 Apr 2009 09:49:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33FPao5002676; Fri, 3 Apr 2009 10:25:36 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33FPaLG002675; Fri, 3 Apr 2009 10:25:36 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 10:25:36 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], [e-mail], Mark Novak <[e-mail]>, Larry Zhu <[e-mail]>, Sam Hartman <[e-mail]>, Leif Johansson <[e-mail]>, Paul Leach <[e-mail]>, Jeffrey Altman <[e-mail]>, Kevin Damour <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland wrote:
> > - By hard-coding a hash function we'd lose hash agility.  Hash  
> >agility is one of the features of the registered tls-server-end-point
> >channel binding type.  OTOH, as you note, for SCRAM this is solved by
> >the existing SCRAM hash agility approach (add a new mech).
> >
> Yes - it's not ideal, but I'm hoping that by the time hash agility  
> becomes an issue, then we'll have support for the more generic form  
> of the channel binding.

The lack of negotiability of which channel binding type to use makes
this not a good answer (but see below).

> > - We can't really negotiate which type of channel binding to use.   
> >It's relatively easy to choose between unique and server-end-point,
> >but to choose between two types of server-end-point bindings is much
> >harder (unless it's a choice made at specification time, in this case
> >for SASL/SCRAM).
> >
> But clients must stipulate which they have used.

That doesn't mean it's negotiable.  GSS-API semantics do not allow the
acceptor to find out what channel binding type the client used.

We could put the channel binding type in the GS2 header -- that would
solve that problem.  But still, the server now has to support multiple
channel binding types and now we need a way to advertise that to the
client -- otherwise the client and server could disagree and fail to
authenticate.

> >   Neither modifying tls-server-end-point nor introducing a  
> >different variant of it seem particularly appealing.  The former may
> >well  be out of the barn's doors, which would leave us only with the
> >latter choice (or fix the TLS frameworks :)
> 
> I think tls-server-end-point is a fine binding.
> 
> My problem is that it'll be years before it's available on many  
> platforms, and I think we can provide more immediately implementable  
> security than that.

Pasi's comment indicates that your premise for this thread is wrong.  I
don't know though.  Can you comment on Pasi's comments?  Are there any
commonly used TLS implementations that encode the server cert
differently on the wire than in their APIs for getting at the server
cert?  I seriously doubt that on the _client_ side, but also, I doubt it
on the server side.  Why would anyone want to write code to re-encode
certs on the fly when that can be done once at configuration time, or
never at all if the CA just does the right thing and issues a DER
certificate.

Also, even if there were implementations that re-encode non-DER certs
into DER for that API, surely, surely one could re-encode the cert at
configuration time so that it's in DER to begin with as far as the TLS
implementation goes -- then there's no need to re-encode as re-encoding
would be the identity function.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FWnOY096903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 08:32:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33FWmR7096902; Fri, 3 Apr 2009 08:32:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FWc45096869 for <[e-mail]>; Fri, 3 Apr 2009 08:32:48 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33FWbOO028458 for <[e-mail]>; Fri, 3 Apr 2009 15:32:38 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 n33FWba5016862 for <[e-mail]>; Fri, 3 Apr 2009 09:32:37 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33FFnfJ002670; Fri, 3 Apr 2009 10:15:49 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33FFmjJ002669; Fri, 3 Apr 2009 10:15:48 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 10:15:48 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <6164.1238756613.878400@puncture>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6164.1238756613.878400@puncture>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 12:03:33PM +0100, Dave Cridland wrote:
> On Thu Apr  2 17:21:23 2009, Nicolas Williams wrote:
> >Jeff Hutzelman points out that we can't introduce multiple variants  
> >of
> >tls-server-endpoint on a per-mechanism basis.  We can do that for  
> >SASL
> >apps generally, say, but not just for SCRAM.
> >
> >
> Right, I agree. Luckily, we can mandate server-side support for  
> additional channel bindings across the board.

Yes, but I don't think we should.  Pasi points out that TLS
implementations generally put the DER encoded cert on the wire.  So I
think the premise of your request for a variant of tls-server-end-point
is in question...  Can you comment on Pasi's comment?

> > Implementations of TLS that don't provide application access to the
> >server cert as it appears on the wire in TLS should just be  
> >extended.
> 
> Will sir be needing to borrow a forklift to help with his upgrade?

If Pasi is right, then no, I won't be :)

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FRTiJ096559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 08:27:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33FRTs2096558; Fri, 3 Apr 2009 08:27:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FREhO096534 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 3 Apr 2009 08:27:29 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n33FREoh027583 for <[e-mail]>; Fri, 3 Apr 2009 15:27:14 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 n33FREpv012393 for <[e-mail]>; Fri, 3 Apr 2009 09:27:14 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33FAPIJ002662; Fri, 3 Apr 2009 10:10:25 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33FAPMw002661; Fri, 3 Apr 2009 10:10:25 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 10:10:25 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 10:01:58AM -0500, Nicolas Williams wrote:
> IF we're going to allow the server/acceptor-may-ignore-client-channel-
> bindings-by-providing-none semantic then we must provide some indication
> that this happened in the server's last message.  But because we need
> this to be communicated to the client at the GS2 layer too, and securely
> so, we'd be complicating GS2 significantly -- I don't think we want
> that.

Actually, there's a simple way to make that possible: put the mechanism
name in the GS2 channel binding data header.  If the name ends in -PLUS
then the server can't ignore the channel bindings because it must have
advertised that it supports them.  Whereas if the name does not end in
-PLUS then the server is free to ignore the client's channel bindings.

Comments?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FIx3w095713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 08:18:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33FIxKP095712; Fri, 3 Apr 2009 08:18:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FIm53095689 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 3 Apr 2009 08:18:58 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n33FIlrH000384 for <[e-mail]>; Fri, 3 Apr 2009 15:18:48 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33FIlTD006803 for <[e-mail]>; Fri, 3 Apr 2009 09:18:47 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33F1x2F002650; Fri, 3 Apr 2009 10:01:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33F1wUt002649; Fri, 3 Apr 2009 10:01:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 10:01:58 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <6164.1238756626.089786@puncture>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6164.1238756626.089786@puncture>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 12:03:46PM +0100, Dave Cridland wrote:
> Then the client provides a tls-server-end-point (or not, because it  
> can't, see previous mails) and the server just ignores it, being  
> unable to verify it, or else rejects the authentication. This would  

The GSS-API does allow the acceptor to ignore channel bindings by not
providing any.  Well, actually, the GSS-API specs are a bit fuzzy on
this point, but for years the MIT krb5 implementation of the krb5 mech
actually worked that way, so there's precedent...  But one could have
mechanisms that don't allow the acceptor to ignore the channel binding
(imagine mixing the channel binding into a key derivation step).

IF we're going to allow the server/acceptor-may-ignore-client-channel-
bindings-by-providing-none semantic then we must provide some indication
that this happened in the server's last message.  But because we need
this to be communicated to the client at the GS2 layer too, and securely
so, we'd be complicating GS2 significantly -- I don't think we want
that.


> only happen when the server is not behind a concentrator, but can  
> only do tls-unique due to TLS API limitations, though - if the server  
> is behind a concentrator and hasn't been configured with its own TLS  
> identity, then one assumes it'd not offer -PLUS.

Correct -- the server must know if it is behind a concentrator, and it
must know its server cert.  Virtualization -> more communication between
the concentrator and the server than just manual configuration.

> Equally interesting is if the server can only do  
> tls-server-end-point, due to being behind a concentrator, but the  
> client can only do tls-unique because it doesn't have a TLS stack  
> which'll provide it with the relevant data.

In that case the client either must force the use of anon-anon TLS
cipher suites or it must not use channel binding.

> One assumes the client should just use tls-unique, and the server  
> will, again, ignore it or reject it.

No.  That wouldn't work: the client and the server would both use
different channel bindings and authentication must then fail.  (This
case is distinguished from the case where the server doesn't know the
channel binding and so ignores it.)

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FCK04095091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 08:12:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33FCK1W095090; Fri, 3 Apr 2009 08:12:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33FCIAV095082 for <[e-mail]>; Fri, 3 Apr 2009 08:12:18 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33FCI8C003344 for <[e-mail]>; Fri, 3 Apr 2009 15:12:18 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n33FCHBv000856 for <[e-mail]>; Fri, 3 Apr 2009 09:12:17 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33Elwmt002627; Fri, 3 Apr 2009 09:47:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33Elqwb002626; Fri, 3 Apr 2009 09:47:52 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 09:47:52 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 02:33:47PM +0200, [e-mail] wrote:
> Nicolas Williams wrote:
> 
> > Questions:
> > 
> > 1) Do many/most/all TLS implementations output the DER-encoded form of
> >    the server cert?  Which ones do/don't?
> > 
> > 2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
> >    hard would it be to change this?  (e.g., re-encode the cert and
> >    restart apps?)
> 
> Although the TLS spec doesn't explicitly say this, the on-the-wire
> certificate is DER encoded. There's no field specifying what the
> encoding is, so if you attempt sending PER or XER, it simply won't
> work.

Right, I doubt anyone re-encodes certs in PER or XER :)

It's BER that one should worry about.

> Some implementations might accept some limited subset of BER (to
> work around CA bugs), but even in those cases, nobody's going to
> re-encode it to DER (most likely the CA calculated the signature over
> BER encoded version -- violating all possible standards -- and the
> API would return the octets sent on the wire).

OK, thanks.

> So I don't see any problem in using the tls-server-end-point channel
> binding...

Excellent.  Thanks!

>            (and it seems it would work for OpenPGP, too)

It could be made to, but tls-server-end-point refers to the first cert
in the 'certificate_list' field of the server's Certificate message --
there's no such field in the OpenPGP case.  It'd be a trivial updat to
tls-server-end-point to allow the use of a server's OpenPGP cert though.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33F9EBC094782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 08:09:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33F9EON094780; Fri, 3 Apr 2009 08:09:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33F92r6094773 for <[e-mail]>; Fri, 3 Apr 2009 08:09:12 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33F922l001552 for <[e-mail]>; Fri, 3 Apr 2009 15:09:02 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 n33F92WO063774 for <[e-mail]>; Fri, 3 Apr 2009 09:09:02 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n33EqDlP002638; Fri, 3 Apr 2009 09:52:13 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33EqCKC002637; Fri, 3 Apr 2009 09:52:12 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 3 Apr 2009 09:52:12 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 12:21:56PM +0200, Simon Josefsson wrote:
> > The idea is that when the TLS channel used server certs then the client
> > MUST use tls-server-end-point bindings.  Otherwise it MUST use
> > tls-unique bindings.
> 
> Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.

Ah, it's in SCRAM -- I need to copy that text to GS2.

> > The reason is this: tls-server-end-point bindings can work with existing
> > TLS concentrators (and with implementations that separate TLS in an
> > stunnel-like fashion), therefore it's preferable, BUT, because
> > tls-server-end-point isn't always available but tls-unique is, we
> > REQUIRE falling back on tls-unique when tls-server-end-point is not
> > available.
> 
> How is that negotiated?  Couldn't it be that the client has access to
> tls-server-end-point but not the server, or vice versa?

That would what you call a bug or configuration error.

If a server cert was used then the server should know.  If there's a TLS
concentrator then the server needs to know that and what cert was used,
which creates a bit of a problem in the virtualization case: the server
needs to know which cert was used, but this can be solved and it's a
much smaller problem, I think, than modifying concentrators to provide
tls-unique bindings to servers.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33CYKlv081174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 05:34:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33CYKIq081173; Fri, 3 Apr 2009 05:34:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33CY56o081127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 3 Apr 2009 05:34:17 -0700 (MST) (envelope-from [e-mail])
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n33CXfLq013384; Fri, 3 Apr 2009 15:33:56 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 15:33:55 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 15:33:48 +0300
Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 3 Apr 2009 14:33:47 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Fri, 3 Apr 2009 14:33:47 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
CC: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Date: Fri, 3 Apr 2009 14:33:47 +0200
Subject: RE: TLS endpoint channel bindings in SCRAM
Thread-Topic: TLS endpoint channel bindings in SCRAM
Thread-Index: AcmzIVyLFrIwMFOjQXm6luyyF7ZehABNXNrQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Apr 2009 12:33:48.0305 (UTC) FILETIME=[6FD3E810:01C9B458]
X-Nokia-AV: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

> Questions:
>=20
> 1) Do many/most/all TLS implementations output the DER-encoded form of
>    the server cert?  Which ones do/don't?
>=20
> 2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
>    hard would it be to change this?  (e.g., re-encode the cert and
>    restart apps?)

Although the TLS spec doesn't explicitly say this, the on-the-wire
certificate is DER encoded. There's no field specifying what the
encoding is, so if you attempt sending PER or XER, it simply won't
work.

Some implementations might accept some limited subset of BER (to
work around CA bugs), but even in those cases, nobody's going to
re-encode it to DER (most likely the CA calculated the signature over
BER encoded version -- violating all possible standards -- and the
API would return the octets sent on the wire).

So I don't see any problem in using the tls-server-end-point channel
binding... (and it seems it would work for OpenPGP, too)

Best regards,
Pasi=



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33B3pGY070921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 04:03:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33B3phP070920; Fri, 3 Apr 2009 04:03:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33B3dKC070895 for <[e-mail]>; Fri, 3 Apr 2009 04:03:51 -0700 (MST) (envelope-from [e-mail])
Received: from puncture (turner.dave.cridland.net [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Fri, 3 Apr 2009 12:03:46 +0100
X-SMTP-Protocol-Errors: PIPELINING
Subject: Re: TLS endpoint channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <6164.1238756626.089786@puncture>
Date: Fri, 03 Apr 2009 12:03:46 +0100
From: Dave Cridland <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: <[e-mail]>, Nicolas Williams <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri Apr  3 11:21:56 2009, Simon Josefsson wrote:
> Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like  
> that.

It's in the latest SCRAM.

> How is that negotiated?  Couldn't it be that the client has access  
> to
> tls-server-end-point but not the server, or vice versa?

Then the client provides a tls-server-end-point (or not, because it  
can't, see previous mails) and the server just ignores it, being  
unable to verify it, or else rejects the authentication. This would  
only happen when the server is not behind a concentrator, but can  
only do tls-unique due to TLS API limitations, though - if the server  
is behind a concentrator and hasn't been configured with its own TLS  
identity, then one assumes it'd not offer -PLUS.

Equally interesting is if the server can only do  
tls-server-end-point, due to being behind a concentrator, but the  
client can only do tls-unique because it doesn't have a TLS stack  
which'll provide it with the relevant data.

One assumes the client should just use tls-unique, and the server  
will, again, ignore it or reject it.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33B3pFX070913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 04:03:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33B3pCZ070912; Fri, 3 Apr 2009 04:03:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33B3dKB070895 for <[e-mail]>; Fri, 3 Apr 2009 04:03:50 -0700 (MST) (envelope-from [e-mail])
Received: from puncture (turner.dave.cridland.net [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Fri, 3 Apr 2009 12:03:37 +0100
Subject: Re: TLS endpoint channel bindings in SCRAM
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <6164.1238756613.878400@puncture>
Date: Fri, 03 Apr 2009 12:03:33 +0100
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu Apr  2 17:21:23 2009, Nicolas Williams wrote:
> Jeff Hutzelman points out that we can't introduce multiple variants  
> of
> tls-server-endpoint on a per-mechanism basis.  We can do that for  
> SASL
> apps generally, say, but not just for SCRAM.
> 
> 
Right, I agree. Luckily, we can mandate server-side support for  
additional channel bindings across the board.


> Simon points out that TLS supports non-PKIX certificates.
> 
> 
Absolutely. However, I'd also state that the prevelant use of TLS is  
with X.509 certificates, and whilst I'm not arguing that this should  
be mandated, I do think we ought to take this into account, and  
indeed take advantage of it to promote deployment of channel binding.

> I agree with these points.

As do I.

>   Therefore I have to say that it's best to
> stick with tls-server-endpoint and not define any new ones, nor to  
> seek
> any changes to tls-server-endpoint.
> 
> 
I fail to see where you get this conclusion from.

>  Implementations of TLS that don't provide application access to the
> server cert as it appears on the wire in TLS should just be  
> extended.

Will sir be needing to borrow a forklift to help with his upgrade?

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33AMD9U068090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 03:22:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n33AMD9V068089; Fri, 3 Apr 2009 03:22:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n33AM1WV068073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 3 Apr 2009 03:22:12 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LpgX7-0006DV-Fq; Fri, 03 Apr 2009 12:21:58 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090403:[e-mail]::7TFs+dwTuJS+7Anj:6+Gt
X-Hashcash: 1:22:090403:[e-mail]::qeR/8/YtXhldhoBo:5OZP
X-Hashcash: 1:22:090403:[e-mail]::q5ot2vIh16uGhMxa:INXZ
Date: Fri, 03 Apr 2009 12:21:56 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Thu, 2 Apr 2009 23:58:42 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Fri, Apr 03, 2009 at 02:40:30AM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
>> >> Simon points out that TLS supports non-PKIX certificates.
>> >
>> > Actually, that's true, but the way RFC5081 adds support for OpenPGP
>> > certs happens to not work with tls-server-end-point bindings because
>> > there's no certificate_list field in the Certificate message when
>> > OpenPGP certs are negotiated.  It would not be difficult to change
>> > tls-server-end-point to cover the use of OpenPGP certs.
>> 
>> Does that mean SCRAM will require server certs?  I think that is
>> unfortunate -- why can't SCRAM over TLS-anon or TLS-PSK or TLS-SRP with
>> tls-unique be supported?
>
> No, no.
>
> The idea is that when the TLS channel used server certs then the client
> MUST use tls-server-end-point bindings.  Otherwise it MUST use
> tls-unique bindings.

Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.

> The reason is this: tls-server-end-point bindings can work with existing
> TLS concentrators (and with implementations that separate TLS in an
> stunnel-like fashion), therefore it's preferable, BUT, because
> tls-server-end-point isn't always available but tls-unique is, we
> REQUIRE falling back on tls-unique when tls-server-end-point is not
> available.

How is that negotiated?  Couldn't it be that the client has access to
tls-server-end-point but not the server, or vice versa?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n335Fs7K050098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 22:15:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n335FsCB050097; Thu, 2 Apr 2009 22:15:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n335FgMQ050088 for <[e-mail]>; Thu, 2 Apr 2009 22:15:53 -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 n335Fgk3020932 for <[e-mail]>; Fri, 3 Apr 2009 05:15:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n335FgN2040846 for <[e-mail]>; Thu, 2 Apr 2009 23:15:42 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n334wqsT002435; Thu, 2 Apr 2009 23:58:52 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n334wgNe002434; Thu, 2 Apr 2009 23:58:42 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 2 Apr 2009 23:58:42 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Apr 03, 2009 at 02:40:30AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
> >> Simon points out that TLS supports non-PKIX certificates.
> >
> > Actually, that's true, but the way RFC5081 adds support for OpenPGP
> > certs happens to not work with tls-server-end-point bindings because
> > there's no certificate_list field in the Certificate message when
> > OpenPGP certs are negotiated.  It would not be difficult to change
> > tls-server-end-point to cover the use of OpenPGP certs.
> 
> Does that mean SCRAM will require server certs?  I think that is
> unfortunate -- why can't SCRAM over TLS-anon or TLS-PSK or TLS-SRP with
> tls-unique be supported?

No, no.

The idea is that when the TLS channel used server certs then the client
MUST use tls-server-end-point bindings.  Otherwise it MUST use
tls-unique bindings.

The reason is this: tls-server-end-point bindings can work with existing
TLS concentrators (and with implementations that separate TLS in an
stunnel-like fashion), therefore it's preferable, BUT, because
tls-server-end-point isn't always available but tls-unique is, we
REQUIRE falling back on tls-unique when tls-server-end-point is not
available.

> > Aside: if I read RFC5081 correctly it seems that you can't negotiate the
> > use of OpenPGP certs for user certs but not for server certs, and vice
> > versa.  Odd!
> 
> That is right.  It also does not permit negotiating X.509 on one side
> and OpenPGP on the other.  There is a -bis effort in progress, but I
> don't think it addresses these concerns.

Well, it should.  I think it makes sense to use PKIX for the server cert
and OpenPGP for the user cert.  I'm not sure that I care enough to go
comment on this.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n330el2D038937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 17:40:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n330el2x038936; Thu, 2 Apr 2009 17:40:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n330eYsl038925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 2 Apr 2009 17:40:46 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LpXSR-0005oK-BE; Fri, 03 Apr 2009 02:40:31 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090403:[e-mail]::mzgWjou4NSjeUQNn:1GX3
X-Hashcash: 1:22:090403:[e-mail]::dLhIqjbfyO7AriRG:CKK/
X-Hashcash: 1:22:090403:[e-mail]::qz79OFqKma1bu5Co:eQgt
Date: Fri, 03 Apr 2009 02:40:30 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Thu, 2 Apr 2009 16:40:44 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
>> Simon points out that TLS supports non-PKIX certificates.
>
> Actually, that's true, but the way RFC5081 adds support for OpenPGP
> certs happens to not work with tls-server-end-point bindings because
> there's no certificate_list field in the Certificate message when
> OpenPGP certs are negotiated.  It would not be difficult to change
> tls-server-end-point to cover the use of OpenPGP certs.

Does that mean SCRAM will require server certs?  I think that is
unfortunate -- why can't SCRAM over TLS-anon or TLS-PSK or TLS-SRP with
tls-unique be supported?

> Aside: if I read RFC5081 correctly it seems that you can't negotiate the
> use of OpenPGP certs for user certs but not for server certs, and vice
> versa.  Odd!

That is right.  It also does not permit negotiating X.509 on one side
and OpenPGP on the other.  There is a -bis effort in progress, but I
don't think it addresses these concerns.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32LvhQl029716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 14:57:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n32LvhrT029715; Thu, 2 Apr 2009 14:57:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32LvWs8029670 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 2 Apr 2009 14:57:43 -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 n32LvWvt013331 for <[e-mail]>; Thu, 2 Apr 2009 21:57:32 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 n32LvV2t011799 for <[e-mail]>; Thu, 2 Apr 2009 15:57:32 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32Lei0Z002196; Thu, 2 Apr 2009 16:40:44 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32LeipA002195; Thu, 2 Apr 2009 16:40:44 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 2 Apr 2009 16:40:44 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
> Simon points out that TLS supports non-PKIX certificates.

Actually, that's true, but the way RFC5081 adds support for OpenPGP
certs happens to not work with tls-server-end-point bindings because
there's no certificate_list field in the Certificate message when
OpenPGP certs are negotiated.  It would not be difficult to change
tls-server-end-point to cover the use of OpenPGP certs.

Aside: if I read RFC5081 correctly it seems that you can't negotiate the
use of OpenPGP certs for user certs but not for server certs, and vice
versa.  Odd!



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GcCQj005418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 09:38:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n32GcCHu005417; Thu, 2 Apr 2009 09:38: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-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GcBYl005410 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 2 Apr 2009 09:38:12 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n32GcBo9018527 for <[e-mail]>; Thu, 2 Apr 2009 16:38:11 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n32GcAeG029919 for <[e-mail]>; Thu, 2 Apr 2009 10:38:10 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32GLNeF002014; Thu, 2 Apr 2009 11:21:23 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32GLNwc002013; Thu, 2 Apr 2009 11:21:23 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 2 Apr 2009 11:21:23 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail]
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff Hutzelman points out that we can't introduce multiple variants of
tls-server-endpoint on a per-mechanism basis.  We can do that for SASL
apps generally, say, but not just for SCRAM.

Simon points out that TLS supports non-PKIX certificates.

I agree with these points.  Therefore I have to say that it's best to
stick with tls-server-endpoint and not define any new ones, nor to seek
any changes to tls-server-endpoint.

Implementations of TLS that don't provide application access to the
server cert as it appears on the wire in TLS should just be extended.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GXMmC005232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 09:33:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n32GXMZx005231; Thu, 2 Apr 2009 09:33:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GXBO7005220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 2 Apr 2009 09:33:22 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.108] (72-63-140-217.pools.spcsdns.net [72.63.140.217]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n32GX6S7028396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 12:33:08 -0400 (EDT)
Date: Thu, 02 Apr 2009 12:33:06 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, April 02, 2009 11:09:25 AM -0500 Nicolas Williams 
<[e-mail]> wrote:

> Chris believes that mechanism names will leak into configuration UIs,

...

> Chris proposed that we just call it "SCRAM1" -- we don't need the
> algorithm names in the mechanism name.  I agree with that.

These positions seem to be inconsistent.  If the mechanism names are going 
to leak into the UI, then I think we owe it to users to use a name that is 
actually descriptive of the mechanism.  I'd much rather have "SCRAM-SHA-1" 
and "SCRAM-SHA-256" and "SCRAM-SHA-3" than "SCRAM1", "SCRAM2", and 
"SCRAM3"; the latter are fairly useless.


I can accept the argument that the -PLUS needs to be meaningful to humans, 
though I suspect the right answer here is that those mechanisms should be 
hidden in configuration UI's -- the UI should treat SCRAM and SCRAM-PLUS as 
if they were the same mechanism, and choose between them appropriately. 
But if we use an affix like -PLUS, we're effectively limiting GSS-API 
mechanisms (and potentially, any mechanism with autonegotiated optional CB 
support) to a 15-character base name.  The GS2 spec should make this clear.

> see the latest GS2 I-D)

I tried, but I couldn't figure out which one it is. :-(



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GRUQI004886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 09:27:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n32GRUJJ004885; Thu, 2 Apr 2009 09:27:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GRJqu004872 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 2 Apr 2009 09:27:30 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n32GR7FU014383 for <[e-mail]>; Thu, 2 Apr 2009 16:27:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n32GR6NN040526 for <[e-mail]>; Thu, 2 Apr 2009 10:27:07 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32G2naX001994; Thu, 2 Apr 2009 11:02:49 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32G2mPn001993; Thu, 2 Apr 2009 11:02:48 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 2 Apr 2009 11:02:48 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <4871.1238666327.232544@puncture>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4871.1238666327.232544@puncture>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Apr 02, 2009 at 10:58:47AM +0100, Dave Cridland wrote:
> 
> On Thu Apr  2 04:52:02 2009, Jeffrey Hutzelman wrote:
> >Finally...  What in the world were jgm et al thinking, limiting  
> >mechanism names to 20 characters and a relatively small symbol set?  
> > Now there are only 3.12E+39 possible SASL mechanism names; what  
> >ever will we do?
> 
> There's also the pressing problem of internationalized SASL mechanism  
> names.
> 
> Oh, wait, what day is it?

A day too late :)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GQRJI004816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 09:26:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n32GQRfw004815; Thu, 2 Apr 2009 09:26:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32GQGph004781 for <[e-mail]>; Thu, 2 Apr 2009 09:26:26 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n32GQFX9008292 for <[e-mail]>; Thu, 2 Apr 2009 16:26:15 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 n32GQF1G040034 for <[e-mail]>; Thu, 2 Apr 2009 10:26:15 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n32G9SOY002000; Thu, 2 Apr 2009 11:09:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n32G9PEE001999; Thu, 2 Apr 2009 11:09:25 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 2 Apr 2009 11:09:25 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 01, 2009 at 11:52:02PM -0400, Jeffrey Hutzelman wrote:
> For starters, I think we should not algorithmically modify mechanism names; 
> instead, any GSS-API mechanism (including SCRAM) that wishes to define 
> friendly SASL mechanism names should define two such names, for the "PLUS" 
> and "non-PLUS" cases.  This makes it easier to express the requirement that 
> these names be registered in the SASL mechanism name registry and not 
> conflict with the names of any existing (or future) SASL mechanisms.

OTOH, having a common affix for "server supports channel binding" makes
it easier to implement a common mechanism selection function in a
client-side SASL framework.

Yes, it wouldn't be hard for such a framework to ask each mechanism
plugin what names it has and which indicate "server supports channel
binding"...

> Secondly, I'd propose including the "plus" bit before the algorithm:
> 
> GS2B-oidoidoidoidoid (basic)
> GS2P-oidoidoidoidoid (plus)
> 
> SCRAM_B-HMAC-SHA-1   (basic)
> SCRAM_P-HMAC-SHA-1   (plus)
> SCRAM_P-HMAC-SHA-256 (plus)

Chris believes that mechanism names will leak into configuration UIs,
and that therefore it's important that the -PLUS affix be meaningful to
humans.  I think we can leave the affix as an implementation detail
(e.g., the user configured "SCRAM" but the client and server will
understand that SCRAM-PLUS is also allowed unless the user specifically
disallowed channel binding).

> Thirdly, if we are in a pinch, we can abbreviate, like s/SHA-1/SHA1/ or 
> removing or abbreviating the "HMAC" component, which is mostly redundant.

Chris proposed that we just call it "SCRAM1" -- we don't need the
algorithm names in the mechanism name.  I agree with that.  That way the
-PLUS suffix becomes a non-issue for SCRAM (it's already a non-issue for
GS2 -- see the latest GS2 I-D).

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32BWRUo080150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 04:32:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n32BWRoO080149; Thu, 2 Apr 2009 04:32:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n32BWPBD080143 for <[e-mail]>; Thu, 2 Apr 2009 04:32:26 -0700 (MST) (envelope-from [e-mail])
Received: from puncture (turner.dave.cridland.net [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Thu, 2 Apr 2009 12:32:23 +0100
Subject: Re: TLS endpoint channel bindings in SCRAM
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <4871.1238671941.558047@puncture>
Date: Thu, 02 Apr 2009 12:32:21 +0100
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, Mark Novak <[e-mail]>, Larry Zhu <[e-mail]>, Sam Hartman <[e-mail]>, Leif Johansson <[e-mail]>, Paul Leach <[e-mail]>, Jeffrey Altman <[e-mail]>, Kevin Damour <[e-mail]>, Stefan Santesson <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed Apr  1 23:52:20 2009, Nicolas Williams wrote:
> 1) Do many/most/all TLS implementations output the DER-encoded form  
> of
>    the server cert?  Which ones do/don't?
> 
> 
Somewhere between many and most. I suspect all the low-level TLS  
stacks (OpenSSL etc) will do. It's the bindings and suchlike I'm more  
concerned with.

In the bindings, however, it's pretty trivial to find a function  
which either hands back the DER form, or else hands back PEM (base64  
of DER), which developers can also use.


> 2) Is the cert used on the wire generally NOT DER-encoded?  If so,  
> how
>    hard would it be to change this?  (e.g., re-encode the cert and
>    restart apps?)
> 
> 
I have absolutely no idea. If I could rely on the cert being DER on  
the wire, we could reduce this to implementation notes, aside from  
the hash issue. I have no idea how to extract that hash algorithm,  
currently, but I could probably figure that out eventually.

If it turns out that tls-server-endpoint *can* be readily implemented  
at least for the common case of X.509 certificates, then I'd be very  
much happier with this outcome.

>  - By hard-coding a hash function we'd lose hash agility.  Hash  
> agility
>    is one of the features of the registered tls-server-end-point  
> channel
>    binding type.  OTOH, as you note, for SCRAM this is solved by the
>    existing SCRAM hash agility approach (add a new mech).
> 
> 
Yes - it's not ideal, but I'm hoping that by the time hash agility  
becomes an issue, then we'll have support for the more generic form  
of the channel binding.


>  - We can't really negotiate which type of channel binding to use.   
> It's
>    relatively easy to choose between unique and server-end-point,  
> but to
>    choose between two types of server-end-point bindings is much  
> harder
>    (unless it's a choice made at specification time, in this case  
> for
>    SASL/SCRAM).
> 
> 
But clients must stipulate which they have used.


>    Neither modifying tls-server-end-point nor introducing a  
> different
>    variant of it seem particularly appealing.  The former may well  
> be
>    out of the barn's doors, which would leave us only with the  
> latter
>    choice (or fix the TLS frameworks :)

I think tls-server-end-point is a fine binding.

My problem is that it'll be years before it's available on many  
platforms, and I think we can provide more immediately implementable  
security than that.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n329x3CB072992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 02:59:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n329x3X9072991; Thu, 2 Apr 2009 02:59:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n329wqLn072967 for <[e-mail]>; Thu, 2 Apr 2009 02:59:03 -0700 (MST) (envelope-from [e-mail])
Received: from puncture (turner.dave.cridland.net [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Thu, 2 Apr 2009 10:58:50 +0100
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <4871.1238666327.232544@puncture>
Date: Thu, 02 Apr 2009 10:58:47 +0100
From: Dave Cridland <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu Apr  2 04:52:02 2009, Jeffrey Hutzelman wrote:
> Finally...  What in the world were jgm et al thinking, limiting  
> mechanism names to 20 characters and a relatively small symbol set?  
>  Now there are only 3.12E+39 possible SASL mechanism names; what  
> ever will we do?

There's also the pressing problem of internationalized SASL mechanism  
names.

Oh, wait, what day is it?

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n328RhCe065281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 01:27:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n328RhsW065280; Thu, 2 Apr 2009 01:27:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n328RUtx065265 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 2 Apr 2009 01:27:42 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LpIGe-00042U-84; Thu, 02 Apr 2009 10:27:20 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Dave Cridland <[e-mail]>, Mark Novak <[e-mail]>, [e-mail], Stefan Santesson <[e-mail]>, Larry Zhu <[e-mail]>, [e-mail], Paul Leach <[e-mail]>, Kevin Damour <[e-mail]>, Jeffrey Altman <[e-mail]>, Sam Hartman <[e-mail]>
Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090402:[e-mail]::eTJ1T256XNHSrQUA:2HAR
X-Hashcash: 1:22:090402:[e-mail]::H7J3RubcGK0IhSaa:H18
X-Hashcash: 1:22:090402:[e-mail]::3o1i4ht2Tj48+D49:33n4
X-Hashcash: 1:22:090402:[e-mail]::1aosdI0tDFj8A6yo:4Qxf
X-Hashcash: 1:22:090402:[e-mail]::K0dfax7O4ExmC9FW:510D
X-Hashcash: 1:22:090402:[e-mail]::WFPg2QGFWLn50kbP:EX37
X-Hashcash: 1:22:090402:[e-mail]::iXqNGcKJoQx9xppR:GTrX
X-Hashcash: 1:22:090402:[e-mail]::hr/q+nc/nYxr/BmC:WLk4
X-Hashcash: 1:22:090402:[e-mail]::D9+T5KBa2jYtpUw3:V8w0
X-Hashcash: 1:22:090402:[e-mail]::12iVMA0My1xh9Gf9:ch1C
X-Hashcash: 1:22:090402:[e-mail]::+Pr6TrIz7JQECDJ6:sqnU
Date: Thu, 02 Apr 2009 10:27:18 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 1 Apr 2009 17:52:20 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

>> Finally, I'd propose that SCRAM mandates support for the  
>> 'tls-x509-end-point' channel binding for the applicable cases as a  
>> reasonable fallback when support for the more flexible and  
>> future-proof tls-server-end-point binding is not available.
>> 
>> Now I'll wait to get shot down in flames. :-)
>
> No flames.  I think we could do a channel binding type just for SCRAM
> (we did one just for TELNET, after all).  But I think I'd want "DER" in
> the name, that and the hash function name too.

I don't think that will work -- TLS isn't just X.509.  TLS supports
OpenPGP server certs.  Generally, TLS can support other forms of server
authentication too.

I don't want to see SCRAM require use of X.509 server certificates if we
can avoid it.

It seems simple to avoid that here: just request the necessary features
from TLS stacks.  If we don't do that now, we likely won't do it next
time we need a channel binding for some application protocol, and then
TLS interfaces will never have this feature.  Nico volunteered to help
with this for OpenSSL, and I can volunteer to do it for GnuTLS.  We knew
from the start that channel bindings would require changes to TLS
stacks.  The major native C libraries have already been adapted, I
believe, so what remains are any language bindings.  That seems like
Just A Simple Matter Of Programming.

The alternative is to make channel binding type negotiable, something I
recall discussing at lengths earlier.  Nothing came out of that, so RFC
5056 does not support any negotiation.  I'm not sure how well it would
work to add that feature for SCRAM?  But it could be explored.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n323qIUn053186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 20:52:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n323qIb1053185; Wed, 1 Apr 2009 20:52:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n323q6tJ053174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 1 Apr 2009 20:52:17 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.108] (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n323q3O8010897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 23:52:04 -0400 (EDT)
Date: Wed, 01 Apr 2009 23:52:02 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
cc: [e-mail]
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, March 27, 2009 09:02:13 PM -0700 Alexey Melnikov 
<[e-mail]> wrote:

>
> If I can still count, it is 21 US-ASCII character long. But SASL allows
> at most 20 (as per RFC 4422).

Hrm.  Well, we can't s/-PLUS/+/, as plus is not allowed.


For starters, I think we should not algorithmically modify mechanism names; 
instead, any GSS-API mechanism (including SCRAM) that wishes to define 
friendly SASL mechanism names should define two such names, for the "PLUS" 
and "non-PLUS" cases.  This makes it easier to express the requirement that 
these names be registered in the SASL mechanism name registry and not 
conflict with the names of any existing (or future) SASL mechanisms.

Secondly, I'd propose including the "plus" bit before the algorithm:

GS2B-oidoidoidoidoid (basic)
GS2P-oidoidoidoidoid (plus)

SCRAM_B-HMAC-SHA-1   (basic)
SCRAM_P-HMAC-SHA-1   (plus)
SCRAM_P-HMAC-SHA-256 (plus)


Thirdly, if we are in a pinch, we can abbreviate, like s/SHA-1/SHA1/ or 
removing or abbreviating the "HMAC" component, which is mostly redundant.


Finally...  What in the world were jgm et al thinking, limiting mechanism 
names to 20 characters and a relatively small symbol set?  Now there are 
only 3.12E+39 possible SASL mechanism names; what ever will we do?

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n320jdHm044346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 17:45:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n320jdqN044345; Wed, 1 Apr 2009 17:45:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n320jc9h044337 for <[e-mail]>; Wed, 1 Apr 2009 17:45:38 -0700 (MST) (envelope-from [e-mail])
Received: from [10.71.2.32] ((unknown) [205.172.16.173])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SdQKsAA-=[e-mail]>; Thu, 2 Apr 2009 01:45:37 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 21:02:13 -0700
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: SASL WG <[e-mail]>
Subject: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
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>

If I can still count, it is 21 US-ASCII character long. But SASL allows 
at most 20 (as per RFC 4422).




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n320jZ2n044332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 17:45:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n320jZ2G044331; Wed, 1 Apr 2009 17:45:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n320jXcY044322 for <[e-mail]>; Wed, 1 Apr 2009 17:45:34 -0700 (MST) (envelope-from [e-mail])
Received: from [10.71.2.32] ((unknown) [205.172.16.173])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SdQKqgA-=[e-mail]>; Thu, 2 Apr 2009 01:45:33 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 20:58:14 -0700
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Newman <[e-mail]>
CC: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= <[e-mail]>, SASL WG <[e-mail]>
Subject: SCRAM todo: deriving client and server key
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <B5048FA51FC6B2F3E0585454@446E7922C82D299DB29D899F>
In-Reply-To: <B5048FA51FC6B2F3E0585454@446E7922C82D299DB29D899F>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman wrote:

> --On February 23, 2009 8:59:44 -0800 Love H=C3=B6rnquist =C3=85strand=20
> <[e-mail]> wrote:
>
>> Right now the client and server key differences is:
>>
>> ClientKey =3D H(SaltedPassword)
>> ServerKey =3D HMAC(SaltedPassword, salt)
>>
>> Why are the derived by two different methods ? (why not XKey =3D
>> HMAC(SaltedKey, "X key")
>
> I just realized I hadn't mentioned publicly that I think this would be=20
> a good change.
>
> Specifically:
>
> ClientKey =3D HMAC(SaltedPassword, "Client Key")
> ServerKey =3D HMAC(SaltedPassword, "Server Key")
>
> I think this actually makes the algorithm description a bit easier to=20
> understand.  What do others think?

Ok, I've updated my copy of the draft to do that.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n320jSG7044312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 17:45:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n320jSle044311; Wed, 1 Apr 2009 17:45:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n320jFdX044294 for <[e-mail]>; Wed, 1 Apr 2009 17:45:27 -0700 (MST) (envelope-from [e-mail])
Received: from [10.71.2.32] ((unknown) [205.172.16.173])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SdQKjgA-=[e-mail]>; Thu, 2 Apr 2009 01:45:06 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Fri, 27 Mar 2009 20:31:05 -0700
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: Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: New SCRAM and GS2 I-Ds
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Tue, Mar 24, 2009 at 06:13:19PM +0000, Dave Cridland wrote:  
>
>>On Mon Mar 23 16:13:30 2009, Nicolas Williams wrote:    
>>
>>>New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
>>>been posted.
>>>      
>>>
>>A couple of nits - the ABNF has:
>>
>>    ;;cbind-type    = value
>>    ;;cbind-input   = gs2-header [ value ":" cbind-data ]
>>    channel-binding = "c=" base64
>>                      ;; base64 encoding of cbind-input
>>
>>I think the "value" should be "cbind-type", and I think cbind-type =  
>>"tls-unique" / value would be better to make it clear what kind of  
>>stuff is expected there.
>>
>
>Ah, yes, this is a typo.  I need to define cbind-data (*OCTET) and fix
>cbind-input:
>
>     ;;cbind-data    = *OCTET
>     ;;cbind-type    = value
>     ;;cbind-input   = gs2-header [ cbind-type ":" cbind-data ]
>  
>
Changed. I've also added comment about "tls-unique".

>>Also, I wouldn't comment these out.
>>
>>    client-final-message-without-proof =
>>                      [channel-binding ","] nonce [","
>>                      extensions]
>>
>>Channel binding (c=) is no longer optional, so this needs updating.
>>    
>>
>
>Good catch, thanks!
>  
>
Fixed.

>>Otherwise, i think I'm up to date with these changes, and it really  
>>didn't take long, so that's great.
>>
>
>Awesome.
>
>Back to your comments in the room, we can compress the CB flag by
>removing one of its possible values since it'd be possible to
>unambiguously know what that case would be.  I used that trick to remove
>the RFC2743 initial context token header compression flag in the case of
>standard GSS mechs (before: "T" or "F"; now: "" or "F").  But I don't
>think it's worth it.
>  
>
I agree.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n31NGsgE039962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2009 16:16:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n31NGssH039961; Wed, 1 Apr 2009 16:16:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n31NGgfb039941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 1 Apr 2009 16:16:53 -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 n31NGfwT015524 for <[e-mail]>; Wed, 1 Apr 2009 23:16:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n31NGfx4020815 for <[e-mail]>; Wed, 1 Apr 2009 17:16:41 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n31MqOkJ001680; Wed, 1 Apr 2009 17:52:24 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31MqK7n001679; Wed, 1 Apr 2009 17:52:20 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 1 Apr 2009 17:52:20 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail], [e-mail], Mark Novak <[e-mail]>, Larry Zhu <[e-mail]>, Sam Hartman <[e-mail]>, Leif Johansson <[e-mail]>, Paul Leach <[e-mail]>, Jeffrey Altman <[e-mail]>, Kevin Damour <[e-mail]>, Stefan Santesson <[e-mail]>
Subject: Re: TLS endpoint channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 24, 2009 at 10:37:37PM +0000, Dave Cridland wrote:
> Having carefully examined the tls-server-end-point channel binding,  
> I've a bit of a concern.

We should probably be having this discussion on the
[e-mail] list (cc'ed).  Also cc'ed are folks who
participated in the registration of tls-server-end-point.

> One of the sticking points of the tls-unique channel binding is how  
> easy it is to get at the data - OpenSSL provides an API, however it's  
> often not exposed to language bindings such as Python, etc, and other  
> TLS implementations may not provide it at all.

File bugs against them!  If you have a list of such bindings I'll
volunteer to help file and track these bugs.

> I can't find any way of getting at the on-wire representation of the  
> server's certificate, and I can't immediately find a way of  
> discovering which hash algorithm to use, either, in the vast majority  
> of bindings.
> 
> So rather than expect all TLS implementations and bindings to change,  
> I'd like to propose an alternate binding, for use where the server's  
> certificate is an X.509v3 one.
> 
> Specifically, I'd like to use a fixed hash algorithm over the  
> DER-encoded form of the certificate - I'll call this  
> "tls-x509-end-point"

Questions:

1) Do many/most/all TLS implementations output the DER-encoded form of
   the server cert?  Which ones do/don't?

2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
   hard would it be to change this?  (e.g., re-encode the cert and
   restart apps?)

Notes:

 - By hard-coding a hash function we'd lose hash agility.  Hash agility
   is one of the features of the registered tls-server-end-point channel
   binding type.  OTOH, as you note, for SCRAM this is solved by the
   existing SCRAM hash agility approach (add a new mech).

 - We can't really negotiate which type of channel binding to use.  It's
   relatively easy to choose between unique and server-end-point, but to
   choose between two types of server-end-point bindings is much harder
   (unless it's a choice made at specification time, in this case for
   SASL/SCRAM).

   Neither modifying tls-server-end-point nor introducing a different
   variant of it seem particularly appealing.  The former may well be
   out of the barn's doors, which would leave us only with the latter
   choice (or fix the TLS frameworks :)

> The DER form of the certificate is readily available through most  
> bindings, in many cases in a single call, and gives exactly  
> equivalent hash-input as the on-wire format, which is very likely  
> [but not mandated, as far as I can find] to be DER anyway.
> 
> Fixing a hash algorithm simply makes this even easier - the current  
> channel binding uses SHA-256 as a "minimum hash", I'd prefer to use  
> SHA-1, as we're certain to have it for SCRAM.

True.

> Finally, I'd propose that SCRAM mandates support for the  
> 'tls-x509-end-point' channel binding for the applicable cases as a  
> reasonable fallback when support for the more flexible and  
> future-proof tls-server-end-point binding is not available.
> 
> Now I'll wait to get shot down in flames. :-)

No flames.  I think we could do a channel binding type just for SCRAM
(we did one just for TELNET, after all).  But I think I'd want "DER" in
the name, that and the hash function name too.

Comments?

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


Nico
--