Re: WG Last Call: draft-ietf-sasl-scram-02

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/30/09 2:37 PM, Simon Josefsson wrote:
> Alexey Melnikov <[e-mail]> writes:
> 
>> Peter Saint-Andre wrote:
>>
>>>> SECTION 4
>>>>
>>>> Typo: "hashed function" => "hash function"
>>>>
>>>> I think the following text is slightly ambiguous:
>>>>
>>>>   The "-PLUS" suffix is used only when the server supports channel
>>>>   binding to the external channel.  In this case the server will
>>>>   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>>>>   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>>>>   negotiation of the use of channel binding.  See Section 6.
>>>>
>>>> This could be read to mean that if a server does not support channel
>>>> bindings, then it will advertise only all and only SCRAM-SHA-1 (but
>>>> never, say, SCRAM-SHA-256). I think we mean that if a server does not
>>>> support channel bindings, then it will advertise only mechanisms of the
>>>> form SCRAM-SHA-length and never mechanisms of the form
>>>> SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
>>>> other than SHA-1).
>>>>    
>>>>
>>> Alexey and I talked about this in Stockholm. I suggest the following text:
>>>
>>>   The "-PLUS" suffix is used only when the server supports channel
>>>   binding to the external channel.  If the server supports channel
>>>   binding, it will advertise both the "bare" and "plus" versions of
>>>   whatever mechanisms it supports (e.g., if the server supports only
>>>   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
>>>   and SCRAM-SHA-1-PLUS); if the server does not support channel
>>>   binding, then it will advertise only the "bare" version of the
>>>   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
>>>   negotiation of the use of channel binding.  See Section 6.
>>>  
>>>
>> Ok, this text will be in -04.
> 
> Please reassure me that the same change isn't needed in GS2?  I don't
> see any normative words above, and as far as I can tell the described
> behaviour is already covered by other text in both SCRAM and GS2 anyway.

Do you think that the former text was not ambiguous?

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpzeugACgkQNL8k5A2w/vyg8wCgrEuu8HQMk5ZAUBF3dPMedZST
JcMAn0+QED2p/yk2/7pMpU0pMGvOgoAE
=FP8w
-----END PGP SIGNATURE-----


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7164oL3032938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 23:04:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7164oWw032937; Fri, 31 Jul 2009 23:04:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stpeter.im (stpeter.im [207.210.219.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7164j40032928 for <[e-mail]>; Fri, 31 Jul 2009 23:04:49 -0700 (MST) (envelope-from [e-mail])
Received: from squire.local (dsl-251-28.dynamic-dsl.frii.net [216.17.251.28]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A54AE40D03; Sat,  1 Aug 2009 00:04:27 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Fri, 31 Jul 2009 19:14:48 -0400
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Simon Josefsson <[e-mail]>
CC: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/30/09 2:37 PM, Simon Josefsson wrote:
> Alexey Melnikov <[e-mail]> writes:
> 
>> Peter Saint-Andre wrote:
>>
>>>> SECTION 4
>>>>
>>>> Typo: "hashed function" => "hash function"
>>>>
>>>> I think the following text is slightly ambiguous:
>>>>
>>>>   The "-PLUS" suffix is used only when the server supports channel
>>>>   binding to the external channel.  In this case the server will
>>>>   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>>>>   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>>>>   negotiation of the use of channel binding.  See Section 6.
>>>>
>>>> This could be read to mean that if a server does not support channel
>>>> bindings, then it will advertise only all and only SCRAM-SHA-1 (but
>>>> never, say, SCRAM-SHA-256). I think we mean that if a server does not
>>>> support channel bindings, then it will advertise only mechanisms of the
>>>> form SCRAM-SHA-length and never mechanisms of the form
>>>> SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
>>>> other than SHA-1).
>>>>    
>>>>
>>> Alexey and I talked about this in Stockholm. I suggest the following text:
>>>
>>>   The "-PLUS" suffix is used only when the server supports channel
>>>   binding to the external channel.  If the server supports channel
>>>   binding, it will advertise both the "bare" and "plus" versions of
>>>   whatever mechanisms it supports (e.g., if the server supports only
>>>   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
>>>   and SCRAM-SHA-1-PLUS); if the server does not support channel
>>>   binding, then it will advertise only the "bare" version of the
>>>   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
>>>   negotiation of the use of channel binding.  See Section 6.
>>>  
>>>
>> Ok, this text will be in -04.
> 
> Please reassure me that the same change isn't needed in GS2?  I don't
> see any normative words above, and as far as I can tell the described
> behaviour is already covered by other text in both SCRAM and GS2 anyway.

Do you think that the former text was not ambiguous?

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpzeugACgkQNL8k5A2w/vyg8wCgrEuu8HQMk5ZAUBF3dPMedZST
JcMAn0+QED2p/yk2/7pMpU0pMGvOgoAE
=FP8w
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6VAF4bO060379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 03:15:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6VAF4SX060378; Fri, 31 Jul 2009 03:15:04 -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 n6VAF4px060372 for <[e-mail]>; Fri, 31 Jul 2009 03:15:04 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 91BC03A68D2; Fri, 31 Jul 2009 03:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-scram-04.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 31 Jul 2009 03: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           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-04.txt
	Pages           : 34
	Date            : 2009-07-31

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

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-04.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-scram-04.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 n6V9U8xA056297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 02:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V9U8Oa056296; Fri, 31 Jul 2009 02:30:08 -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 n6V9U7wS056287 for <[e-mail]>; Fri, 31 Jul 2009 02:30:07 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id CA4653A6BDB; Fri, 31 Jul 2009 02:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-gs2-15.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri, 31 Jul 2009 02: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           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson, N. Williams
	Filename        : draft-ietf-sasl-gs2-15.txt
	Pages           : 24
	Date            : 2009-07-31

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-15.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-15.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 n6V8Vvow051850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 01:31:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V8VvHC051849; Fri, 31 Jul 2009 01:31: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 n6V8Vuec051842 for <[e-mail]>; Fri, 31 Jul 2009 01:31:56 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 31 Jul 2009 09:31:55 +0100
Message-ID: <[e-mail]>
Date: Fri, 31 Jul 2009 10:31:46 +0200
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: Tom Yu <[e-mail]>
CC: [e-mail]
Subject: Re: SASL IETF75 summary
References: <[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>

Tom Yu wrote:
 [...]

>Drop EXTERNAL from base spec?  No consensus either way.  Probably not
>a big deal; could possibly get folded into Simon's external-channel
>draft.
>
I think I've heard some support for removing SASL EXTERNAL from the base 
spec.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V7mSkO048425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 00:48:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V7mSLO048424; Fri, 31 Jul 2009 00:48: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 n6V7mQoM048418 for <[e-mail]>; Fri, 31 Jul 2009 00:48:27 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 31 Jul 2009 08:48:25 +0100
Message-ID: <[e-mail]>
Date: Fri, 31 Jul 2009 09:48:21 +0200
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: Peter Saint-Andre <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>
>>Peter Saint-Andre wrote:    
>>
>>>>SECTION 4
>>>>
>>>>Typo: "hashed function" => "hash function"
>>>>
>>>>I think the following text is slightly ambiguous:
>>>>
>>>>  The "-PLUS" suffix is used only when the server supports channel
>>>>  binding to the external channel.  In this case the server will
>>>>  advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>>>>  server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>>>>  negotiation of the use of channel binding.  See Section 6.
>>>>
>>>>This could be read to mean that if a server does not support channel
>>>>bindings, then it will advertise only all and only SCRAM-SHA-1 (but
>>>>never, say, SCRAM-SHA-256). I think we mean that if a server does not
>>>>support channel bindings, then it will advertise only mechanisms of the
>>>>form SCRAM-SHA-length and never mechanisms of the form
>>>>SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
>>>>other than SHA-1).        
>>>>
>>>Alexey and I talked about this in Stockholm. I suggest the following text:
>>>
>>>  The "-PLUS" suffix is used only when the server supports channel
>>>  binding to the external channel.  If the server supports channel
>>>  binding, it will advertise both the "bare" and "plus" versions of
>>>  whatever mechanisms it supports (e.g., if the server supports only
>>>  SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
>>>  and SCRAM-SHA-1-PLUS); if the server does not support channel
>>>  binding, then it will advertise only the "bare" version of the
>>>  mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
>>>  negotiation of the use of channel binding.  See Section 6.
>>>      
>>>
>>Ok, this text will be in -04.
>>    
>>
>
>Please reassure me that the same change isn't needed in GS2?  I don't
>see any normative words above, and as far as I can tell the described
>behaviour is already covered by other text in both SCRAM and GS2 anyway.
>
While I think Peter's text is an improvement, I don't have a strong 
feeling on whether you need to add it to GS2.

>
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UIc9nP002172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 11:38:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UIc9cK002171; Thu, 30 Jul 2009 11:38: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 n6UIc21u002158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 30 Jul 2009 11:38:08 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6UIbw4T001624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2009 20:38:00 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Peter Saint-Andre <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090730:[e-mail]::wIj45AGW5oH859TT:5WZ+
X-Hashcash: 1:22:090730:[e-mail]::9JmgPnJfiE8vZrVE:JD/D
X-Hashcash: 1:22:090730:[e-mail]::gBMLkOBDSajeObMo:HvW+
Date: Thu, 30 Jul 2009 20:37:58 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 30 Jul 2009 19:55:44 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Peter Saint-Andre wrote:
>
>>>SECTION 4
>>>
>>>Typo: "hashed function" => "hash function"
>>>
>>>I think the following text is slightly ambiguous:
>>>
>>>   The "-PLUS" suffix is used only when the server supports channel
>>>   binding to the external channel.  In this case the server will
>>>   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>>>   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>>>   negotiation of the use of channel binding.  See Section 6.
>>>
>>>This could be read to mean that if a server does not support channel
>>>bindings, then it will advertise only all and only SCRAM-SHA-1 (but
>>>never, say, SCRAM-SHA-256). I think we mean that if a server does not
>>>support channel bindings, then it will advertise only mechanisms of the
>>>form SCRAM-SHA-length and never mechanisms of the form
>>>SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
>>>other than SHA-1).
>>>    
>>>
>>Alexey and I talked about this in Stockholm. I suggest the following text:
>>
>>   The "-PLUS" suffix is used only when the server supports channel
>>   binding to the external channel.  If the server supports channel
>>   binding, it will advertise both the "bare" and "plus" versions of
>>   whatever mechanisms it supports (e.g., if the server supports only
>>   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
>>   and SCRAM-SHA-1-PLUS); if the server does not support channel
>>   binding, then it will advertise only the "bare" version of the
>>   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
>>   negotiation of the use of channel binding.  See Section 6.
>>  
>>
> Ok, this text will be in -04.

Please reassure me that the same change isn't needed in GS2?  I don't
see any normative words above, and as far as I can tell the described
behaviour is already covered by other text in both SCRAM and GS2 anyway.

/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 n6UHtvOD099254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 10:55:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHtv61099253; Thu, 30 Jul 2009 10:55: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 n6UHtsXh099246 for <[e-mail]>; Thu, 30 Jul 2009 10:55:56 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 18:55:51 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 19:55:44 +0200
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: Peter Saint-Andre <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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>

Peter Saint-Andre wrote:

>>SECTION 4
>>
>>Typo: "hashed function" => "hash function"
>>
>>I think the following text is slightly ambiguous:
>>
>>   The "-PLUS" suffix is used only when the server supports channel
>>   binding to the external channel.  In this case the server will
>>   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>>   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>>   negotiation of the use of channel binding.  See Section 6.
>>
>>This could be read to mean that if a server does not support channel
>>bindings, then it will advertise only all and only SCRAM-SHA-1 (but
>>never, say, SCRAM-SHA-256). I think we mean that if a server does not
>>support channel bindings, then it will advertise only mechanisms of the
>>form SCRAM-SHA-length and never mechanisms of the form
>>SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
>>other than SHA-1).
>>    
>>
>Alexey and I talked about this in Stockholm. I suggest the following text:
>
>   The "-PLUS" suffix is used only when the server supports channel
>   binding to the external channel.  If the server supports channel
>   binding, it will advertise both the "bare" and "plus" versions of
>   whatever mechanisms it supports (e.g., if the server supports only
>   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
>   and SCRAM-SHA-1-PLUS); if the server does not support channel
>   binding, then it will advertise only the "bare" version of the
>   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
>   negotiation of the use of channel binding.  See Section 6.
>  
>
Ok, this text will be in -04.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHm3lj098741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 10:48:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHm3Of098740; Thu, 30 Jul 2009 10:48:03 -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 n6UHlvI2098730 for <[e-mail]>; Thu, 30 Jul 2009 10:48:01 -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, 30 Jul 2009 18:47:53 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Peter Saint-Andre <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Date: Thu, 30 Jul 2009 10:47:39 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.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 Jul 30, 2009, at 10:26 AM, Peter Saint-Andre wrote:

> So I looked at this again. The concept of a "simple username" has  
> always
> been fuzzy to me. It is described in the SASLprep document, RFC  
> 4013. It
> seems to be the localpart, not <localpart>[@<domain>] (at least, all  
> the
> examples in RFC 4013 look like localparts).

No.  Simple here means that none of the allowed characters of a  
username have any special semantics.  That is, there is no concept of  
local part or a domain part or even separator in a simple username.   
The username, to SASLprep, is just a sequence of characters.  This, of  
course, doesn't preclude implementations or deployers from attaching  
additional semantics usernames they use... but such semantics are  
completely outside of SASLprep and mechanisms that use "simple user  
names" as defined by SASLprep.

Maybe when RFC 4013 we can add an examples such as "a;b@c:d".

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHj9sn098553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 10:45:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHj96b098552; Thu, 30 Jul 2009 10:45:09 -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 n6UHj4EX098542 for <[e-mail]>; Thu, 30 Jul 2009 10:45:09 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 36E0E3A681D; Thu, 30 Jul 2009 10:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-scram-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 30 Jul 2009 10:45: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           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-03.txt
	Pages           : 34
	Date            : 2009-07-30

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

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-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-scram-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 n6UHXsY1097823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 10:34:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHXsWf097822; Thu, 30 Jul 2009 10:33:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stpeter.im (stpeter.im [207.210.219.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHXrwo097815 for <[e-mail]>; Thu, 30 Jul 2009 10:33:54 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 331E340C89; Thu, 30 Jul 2009 11:33:53 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 19:33:51 +0200
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Tom Yu <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/29/09 1:58 PM, Peter Saint-Andre wrote:

> SECTION 4
> 
> Typo: "hashed function" => "hash function"
> 
> I think the following text is slightly ambiguous:
> 
>    The "-PLUS" suffix is used only when the server supports channel
>    binding to the external channel.  In this case the server will
>    advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>    server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>    negotiation of the use of channel binding.  See Section 6.
> 
> This could be read to mean that if a server does not support channel
> bindings, then it will advertise only all and only SCRAM-SHA-1 (but
> never, say, SCRAM-SHA-256). I think we mean that if a server does not
> support channel bindings, then it will advertise only mechanisms of the
> form SCRAM-SHA-length and never mechanisms of the form
> SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
> other than SHA-1).

Alexey and I talked about this in Stockholm. I suggest the following text:

   The "-PLUS" suffix is used only when the server supports channel
   binding to the external channel.  If the server supports channel
   binding, it will advertise both the "bare" and "plus" versions of
   whatever mechanisms it supports (e.g., if the server supports only
   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
   and SCRAM-SHA-1-PLUS); if the server does not support channel
   binding, then it will advertise only the "bare" version of the
   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
   negotiation of the use of channel binding.  See Section 6.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpx2X8ACgkQNL8k5A2w/vzaoACeJD50PkCzKoLUFsccgU69ooil
1kMAn28bbQCgnvKy3WuXvzx3hZeNYo7v
=92RR
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHQNaX097292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 10:26:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHQN4X097291; Thu, 30 Jul 2009 10:26:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stpeter.im (stpeter.im [207.210.219.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHQMs0097285 for <[e-mail]>; Thu, 30 Jul 2009 10:26:23 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DE09740C89; Thu, 30 Jul 2009 11:26:21 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 19:26:19 +0200
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>            <[e-mail]> <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/30/09 6:38 PM, Alexey Melnikov wrote:
> Peter Saint-Andre wrote:
> 
>> On 7/30/09 11:12 AM, Alexey Melnikov wrote:
>>  
>>
>>> Peter Saint-Andre wrote:
>>>   
> [...]
> 
>>>> SECTION 5.1
>>>>     
>>>> The "n" attribute specifies a username. Is it up to the using protocol
>>>> define exactly what a username is? I am thinking of hosting providers
>>>> that might host multiple domains for a given service, such that the the
>>>> username is not a "local-part" but could include a domain name (XMPP is
>>>> but one example; others might include IMAP).
>>>>     
>>> My copy already says:
>>>   This attribute specifies the name of the
>>>   user whose password is used for
>>>   authentication (a.k.a. "authentication identity" <xref
>>> target='RFC4422'/>).
>>>
>>> And according to RFC 4422, each mechanism defines how authentication
>>> identity looks like.
>>> For SCRAM it is a "simple username" (i.e. <localpart>[@<domain>]), for
>>> Kerberos it is a Kerberos principal, etc.
>>>   
>> My concern is that "the name of the user" could be construed to mean
>> "localpart", which is commonly called the "username" portion of an
>> address.
>>  
>>
> Can you recommend a better text?

So I looked at this again. The concept of a "simple username" has always
been fuzzy to me. It is described in the SASLprep document, RFC 4013. It
seems to be the localpart, not <localpart>[@<domain>] (at least, all the
examples in RFC 4013 look like localparts).

In any case, Alexey and I just talked about this in Stockholm and I
think the confusion comes in from RFC 3920, so I need to fix this in
rfc3920bis.

>>>> For the "n" attribute, "the server SHOULD prepare it using the
>>>> "SASLPrep" profile". Under what circumstances is it appropriate for the
>>>> server to not prepare the value according to SASLPrep?
>>>>     
>>> This is a cut&paste from the DIGEST-MD5 update I was working on. If I
>>> remember correctly there was some objection to making this a MUST. To
>>> this day many implementors don't implement SASLPrep, so I think this is
>>> a reasonable compromise.
>>>   
>>
>> Again, my concern is that some other preparation rule might be
>> appropriate (e.g., in XMPP [e-mail] is prepared according to
>> two separate rules because there is one rule for localpart and another
>> rule for domain).
>>  
>>
> This applies to authorization identities in XMPP. Authorization identity
> format is protocol specific.

I thought that "a" was authorization identity and "n" was authentication
identity, no? In any case, I think the fixes belong in rfc3920bis, so I
shall work on that and remain quiet about this issue in the SCRAM doc.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpx17sACgkQNL8k5A2w/vyNnACgi6Pxy7hZ83tfGBDr/1ux8g7t
U00AoPqTXMsKkpuw3mxh7m2BrPdTZ0lV
=c1Ip
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UGcRlE093226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 09:38:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UGcR6I093224; Thu, 30 Jul 2009 09:38:27 -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 n6UGcJsO093217 for <[e-mail]>; Thu, 30 Jul 2009 09:38:26 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 17:38:17 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 18:38:02 +0200
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: Peter Saint-Andre <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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: 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>

Peter Saint-Andre wrote:

>On 7/30/09 11:12 AM, Alexey Melnikov wrote:
>  
>
>>Peter Saint-Andre wrote:
>>    
>>
 [...]

>>>SECTION 5.1
>>>      
>>>
>>>The "n" attribute specifies a username. Is it up to the using protocol
>>>define exactly what a username is? I am thinking of hosting providers
>>>that might host multiple domains for a given service, such that the the
>>>username is not a "local-part" but could include a domain name (XMPP is
>>>but one example; others might include IMAP).
>>>      
>>>
>>My copy already says:
>>   This attribute specifies the name of the
>>   user whose password is used for
>>   authentication (a.k.a. "authentication identity" <xref
>>target='RFC4422'/>).
>>
>>And according to RFC 4422, each mechanism defines how authentication
>>identity looks like.
>>For SCRAM it is a "simple username" (i.e. <localpart>[@<domain>]), for
>>Kerberos it is a Kerberos principal, etc.
>>    
>>
>My concern is that "the name of the user" could be construed to mean
>"localpart", which is commonly called the "username" portion of an address.
>  
>
Can you recommend a better text?

>>>For the "n" attribute, "the server SHOULD prepare it using the
>>>"SASLPrep" profile". Under what circumstances is it appropriate for the
>>>server to not prepare the value according to SASLPrep?
>>>      
>>>
>>This is a cut&paste from the DIGEST-MD5 update I was working on. If I
>>remember correctly there was some objection to making this a MUST. To
>>this day many implementors don't implement SASLPrep, so I think this is
>>a reasonable compromise.
>>    
>>
>
>Again, my concern is that some other preparation rule might be
>appropriate (e.g., in XMPP [e-mail] is prepared according to
>two separate rules because there is one rule for localpart and another
>rule for domain).
>  
>
This applies to authorization identities in XMPP. Authorization identity 
format is protocol specific.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UGLKgr092054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 09:21:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UGLKcV092053; Thu, 30 Jul 2009 09:21:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stpeter.im (stpeter.im [207.210.219.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UGLDMw092040 for <[e-mail]>; Thu, 30 Jul 2009 09:21:19 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6D66D4007B; Thu, 30 Jul 2009 10:21:12 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 18:21:10 +0200
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/30/09 11:12 AM, Alexey Melnikov wrote:
> Peter Saint-Andre wrote:
> 
>> Some nits...
>>  
>>
> Some of there are more than just nits :-).

Well, they're not huge issues. :)

>> SECTION 3
>>
>> The specification assumes that "the client is in possession of a
>> username and password"; does it make sense to mention the fact that
>> passwordless login can occur in this world (Kerb, X.509, etc.)?
>>  
>>
> I don't think this would help readability. I've changed "the client" to
> "the SCRAM client" in my copy. Is it any better?

I suppose it's fine just to say "the client". My nit was directed elsewhere.

>> SECTION 5.1
>>
>> For the definition of "n", the text says that "a client must include it
>> in its first message to the server"; do we mean MUST here?
>>
> Sure.
> 
>> The "n" attribute specifies a username. Is it up to the using protocol
>> define exactly what a username is? I am thinking of hosting providers
>> that might host multiple domains for a given service, such that the the
>> username is not a "local-part" but could include a domain name (XMPP is
>> but one example; others might include IMAP).
>>  
>>
> My copy already says:
>    This attribute specifies the name of the
>    user whose password is used for
>    authentication (a.k.a. "authentication identity" <xref
> target='RFC4422'/>).
> 
> And according to RFC 4422, each mechanism defines how authentication
> identity looks like.
> For SCRAM it is a "simple username" (i.e. <localpart>[@<domain>]), for
> Kerberos it is a Kerberos principal, etc.

My concern is that "the name of the user" could be construed to mean
"localpart", which is commonly called the "username" portion of an address.

>> For the "n" attribute, "the server SHOULD prepare it using the
>> "SASLPrep" profile". Under what circumstances is it appropriate for the
>> server to not prepare the value according to SASLPrep?
>>
> This is a cut&paste from the DIGEST-MD5 update I was working on. If I
> remember correctly there was some objection to making this a MUST. To
> this day many implementors don't implement SASLPrep, so I think this is
> a reasonable compromise.

Again, my concern is that some other preparation rule might be
appropriate (e.g., in XMPP [e-mail] is prepared according to
two separate rules because there is one rule for localpart and another
rule for domain).

Thanks!

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpxyHYACgkQNL8k5A2w/vyrqACg6XRsoSbUDGztW/1umvLduyHt
frEAn0Fhj9Sq01Yke87BLik6IVhmMdZD
=h6jA
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UBTZAW066582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 04:29:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UBTZiP066581; Thu, 30 Jul 2009 04: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UBTURe066574 for <[e-mail]>; Thu, 30 Jul 2009 04:29:34 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 12:29:27 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 13:29:21 +0200
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: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=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:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>Nicolas Williams <[e-mail]> writes:
>>>      
>>>
>>>>Jeff Hutzelman points out that RFC2744 specifically requires that all
>>>>gss_buffer_t outputs be released.  That wouldn't bother me at all here
>>>>(we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
>>>>RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
>>>>chance to do that and didn't, so I'd say that these output buffers
>>>>should be released by the app.
>>>>        
>>>>
>>>Good catch, I have removed the paragraph.  How memory should be managed
>>>by applications (i.e., they have to be released) then follows directly
>>>
>>>from the normative RFC 2744 and GS2 shouldn't say anything about it.
>>>      
>>>
>>>Alexey, I hope this resolves your question.
>>>      
>>>
>>Can we say that informatively in the document, considering that this
>>mistake was done before?
>>    
>>
>Yep, the variable descriptions now follows the style used by RFC 2743 to
>document this, e.g.:
>
>   o sasl_mech_name UTF-8 STRING -- SASL name for this
>     mechanism; caller must release with
>     GSS_Release_buffer()
>
>Is this clear enough?
>  
>
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 n6UBPRi7056781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 04:25:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UBPRpf056772; Thu, 30 Jul 2009 04:25: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 n6UBPO4u055985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 30 Jul 2009 04:25:26 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-52e8.meeting.ietf.org [130.129.82.232] (may be forged)) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6UBPKsm022249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2009 13:25:22 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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:090730:[e-mail]::GbKXnjYiVz/8g9+D:JBhU
X-Hashcash: 1:22:090730:[e-mail]::1QfFrp0BfKm/I0yz:R/7Z
X-Hashcash: 1:22:090730:[e-mail]::jFojbnr1g0Gq1/cG:ch3B
Date: Thu, 30 Jul 2009 13:25:20 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 30 Jul 2009 13:19:56 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>Nicolas Williams <[e-mail]> writes:
>>  
>>
>>>Jeff Hutzelman points out that RFC2744 specifically requires that all
>>>gss_buffer_t outputs be released.  That wouldn't bother me at all here
>>>(we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
>>>RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
>>>chance to do that and didn't, so I'd say that these output buffers
>>>should be released by the app.
>>>    
>>>
>>Good catch, I have removed the paragraph.  How memory should be managed
>>by applications (i.e., they have to be released) then follows directly
>>from the normative RFC 2744 and GS2 shouldn't say anything about it.
>>Alexey, I hope this resolves your question.
>>  
>>
> Can we say that informatively in the document, considering that this
> mistake was done before?

Yep, the variable descriptions now follows the style used by RFC 2743 to
document this, e.g.:

   o sasl_mech_name UTF-8 STRING -- SASL name for this
     mechanism; caller must release with
     GSS_Release_buffer()

Is this clear enough?

/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 n6UBK827053854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 04:20:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UBK8IM053853; Thu, 30 Jul 2009 04:20:08 -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 n6UBK6Mw053846 for <[e-mail]>; Thu, 30 Jul 2009 04:20:07 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 12:20:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 13:19:56 +0200
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]>, Nicolas Williams <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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>

Simon Josefsson wrote:

>Nicolas Williams <[e-mail]> writes:
>  
>
>>Jeff Hutzelman points out that RFC2744 specifically requires that all
>>gss_buffer_t outputs be released.  That wouldn't bother me at all here
>>(we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
>>RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
>>chance to do that and didn't, so I'd say that these output buffers
>>should be released by the app.
>>    
>>
>Good catch, I have removed the paragraph.  How memory should be managed
>by applications (i.e., they have to be released) then follows directly
>from the normative RFC 2744 and GS2 shouldn't say anything about it.
>Alexey, I hope this resolves your question.
>  
>
Can we say that informatively in the document, considering that this 
mistake was done before?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UB7Ve5052631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 04:07:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UB7VL1052630; Thu, 30 Jul 2009 04:07:31 -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 n6UB7P5Z052619 for <[e-mail]>; Thu, 30 Jul 2009 04:07:26 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 12:07:15 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 11:12:39 +0200
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: Peter Saint-Andre <[e-mail]>
CC: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Saint-Andre wrote:

>Some nits...
>  
>
Some of there are more than just nits :-).
Thank you for the review!
I've responded/addressed most of your comments in my copy, I will reply 
to the rest in a separate message.

>SECTION 2
>
>Typo: "family of mechanism" => "family of mechanisms"
>
Fixed.

>The second paragraph references security layers, which are not
>previously defined
>
Added the reference to RFC 4422.

>(and no reference is made to RFC 5056 here).
>  
>
It is referenced in my copy.

>Under protocol features, the document says that "A standard attribute is
>defined to enable storage of the authentication information in LDAPv3"
>but I don't see where this attribute is defined in the spec.
>  
>
This needs an informative reference to another draft I am editing. I 
will add.

>SECTION 3
>
>The specification assumes that "the client is in possession of a
>username and password"; does it make sense to mention the fact that
>passwordless login can occur in this world (Kerb, X.509, etc.)?
>  
>
I don't think this would help readability. I've changed "the client" to 
"the SCRAM client" in my copy. Is it any better?

>SECTION 4
>
>Typo: "hashed function" => "hash function"
>  
>
 [...]

>SECTION 5
>
>There is an example of "tls-server-end-point" but no reference for this
>channel binding type.
>  
>
I will add an informative reference.

>SECTION 5.1
>
>For the definition of "n", the text says that "a client must include it
>in its first message to the server"; do we mean MUST here?
>
Sure.

>The "n" attribute specifies a username. Is it up to the using protocol
>define exactly what a username is? I am thinking of hosting providers
>that might host multiple domains for a given service, such that the the
>username is not a "local-part" but could include a domain name (XMPP is
>but one example; others might include IMAP).
>  
>
My copy already says:
    This attribute specifies the name of the
    user whose password is used for
    authentication (a.k.a. "authentication identity" <xref 
target='RFC4422'/>).

And according to RFC 4422, each mechanism defines how authentication 
identity looks like.
For SCRAM it is a "simple username" (i.e. <localpart>[@<domain>]), for 
Kerberos it is a Kerberos principal, etc.

>For the "n" attribute, "the server SHOULD prepare it using the
>"SASLPrep" profile". Under what circumstances is it appropriate for the
>server to not prepare the value according to SASLPrep?
>
This is a cut&paste from the DIGEST-MD5 update I was working on. If I 
remember correctly there was some objection to making this a MUST. To 
this day many implementors don't implement SASLPrep, so I think this is 
a reasonable compromise.

>Typo: "It is important that this be value" => "It is important that this
>value be"
>
>Typo: missing close paren after the reference to RFC 5056
>  
>
Both fixed.

>For the "i" attribute, the text says that it "must be sent by the server
>along with the user's salt"; do we mean MUST here?
>  
>
Yes.

>SECTION 6
>
>Typo: "MUST chose" => "MUST choose"
>
>SECTION 8.2
>
>Typo: "SHALL BE" => "SHALL be"
>  
>
Both fixed.

>APPENDIX A
>
>CRAM-MD5 is mentioned as another authentication mechanism, seemingly
>with the meaning that SCRAM is intended to obsolete CRAM-MD5. I recall
>an objection by John Klensin at the mic in San Francisco that in fact
>SCRAM is intended to obsolete DIGEST-MD5 but not CRAM-MD5. But perhaps
>that is a matter for draft-ietf-sasl-crammd5-to-historic, not this
>specification.
>  
>
Agree with the last sentence.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UB7BVX052582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 04:07:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UB7BqW052581; Thu, 30 Jul 2009 04:07: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 n6UB6r2q052538 for <[e-mail]>; Thu, 30 Jul 2009 04:06:58 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 12:06:50 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 10:06:08 +0200
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: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F>
In-Reply-To: <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F>
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>

Chris Newman wrote:

> It's been a while since I read this, so I re-read it from scratch.  
> Mostly editorial nits:
>
> Section 3:
>   implementation may chose to use the same iteration count for all
>   account.)  The server sends the salt and the iteration count to the
>   ^^^^^^^
>   accounts

Fixed.

> Section 7:
>
>>     generic-message = attr-val *("," attr-val)
>>                       ;; Generic syntax of any server challenge
>>                       ;; or client response
>
> I observe that gs2-header does not conform to "generic-message" if it 
> begins with "y" or "n".  This inconsistency could be resolved by 
> removing "generic-message" from the document.

Done.

> Section 10:
>
>>   SASL Mechanisms registry.  IANA is requested to prevent future
>>   registrations of SASL mechanisms starting with SCRAM- without
>>   consulting the SASL mailing list <[e-mail]> first.
>
> This at least needs to designate a successor review process if 
> [e-mail] goes away.

I've added "(or a successor designated by the responsible Security AD)".

> I'd also prefer the document enumerate principles for when to allow 
> registration.  Personally, I consider undesirable to have the family 
> be large.  I'd prefer it contain only SCRAM-SHA-1, and in the future 
> SCRAM-SHA-3 (with the -PLUS variants). Perhaps we could briefly 
> discuss this at the meeting.

I am expecting some text :-).

> I support advancement of this version of the document on the standards 
> track.
>
> I intend to implement it excluding section 8 and SASLprep.  I will 
> attempt to implement channel bindings, but it has gotten fairly 
> complex particularly with all this stuff about different types of 
> channel bindings. I am unsure how difficult it will be to add channel 
> binding support to NSS. In the event I succeed with channel bindings, 
> but subsequently experience interoperability problems with channel 
> bindings, I will remove all channel binding support from my 
> implementation.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UB79Z6052574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 04:07:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UB79rF052573; Thu, 30 Jul 2009 04:07: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 n6UB76xv052560 for <[e-mail]>; Thu, 30 Jul 2009 04:07:07 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 12:07:00 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 10:10:53 +0200
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>
CC: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> --On Tuesday, July 28, 2009 11:05:26 AM +0200 Simon Josefsson 
> <[e-mail]> wrote:
>
>> The IANA section says:
>>
>>    IANA is requested to prevent future registrations of SASL mechanisms
>>    starting with SCRAM- without consulting the SASL mailing list
>>    <[e-mail]> first.
>>
>> I'm not sure how the IANA would parse this request.  Who on this list
>> has authority to say yes or no to IANA?  For clarity, I think we should
>> use one of the terms defined by RFC 2434.  Is this IETF Consensus?  Or
>> Expert Review?  Or Standards Action?
>
> I'm pretty sure it's Expert Review with a mailing list as the expert.  
> But given the agreement we seemed to have during yesterday's meeting 
> that this family should have slow growth accommodating only successor 
> hashes, I think Standards Action would be more appropriate.

I think IESG would prefer a bit of flexibility. What would happen if we 
want to register a SCRAM mechanism for historic reasons (marked as 
"obsolete") in an Informational RFC? So I would rather specify IETF 
Consensus here + provide some guidance on when mechanism should be 
registered.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UB732M052557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 04:07:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UB73DG052556; Thu, 30 Jul 2009 04:07:03 -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 n6UB6jFd052525 for <[e-mail]>; Thu, 30 Jul 2009 04:06:58 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 30 Jul 2009 12:06:42 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Jul 2009 10:04:33 +0200
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: Jeffrey Hutzelman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[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:

>Jeffrey Hutzelman <[e-mail]> writes:  
>
>>--On Monday, July 27, 2009 03:17:20 PM +0200 Chris Newman
>><[e-mail]> wrote:
>>    
>>
>>>Section 10:
>>>      
>>>
>>>>  SASL Mechanisms registry.  IANA is requested to prevent future
>>>>  registrations of SASL mechanisms starting with SCRAM- without
>>>>  consulting the SASL mailing list <[e-mail]> first.
>>>>        
>>>>
>>>This at least needs to designate a successor review process if
>>>[e-mail] goes away.
>>>      
>>>
>>I don't think it does.  There's plenty of precedent for setting up a
>>mailing list as the reviewer; if the list goes away, the IESG can
>>designate a new reviewer.
>>    
>>
>How about changing the e-mail address to [e-mail] so the e-mail
>name is at least under the IETF's control?
>
I don't think this matters much, this is a WG mailing list and IETF has 
control over which mailing lists are used by WGs.

>The address can be a forward
>to this list, if we for some reason don't want to move the list to
>[e-mail] as well.
>  
>
As a side note: I've talked to our AD Pasi (who talked to Paul Hoffman) 
and he said that in a few months this mailing list will migrate to 
@ietf.org.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UAAk36048252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 03:10:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UAAkQt048251; Thu, 30 Jul 2009 03:10:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-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 n6UAAWfk048199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 30 Jul 2009 03:10:45 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-52e8.meeting.ietf.org [130.129.82.232] (may be forged)) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6UAARud020058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2009 12:10:30 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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:090730:[e-mail]::ULRa8mPgra2Sh8tn:0ZNi
X-Hashcash: 1:22:090730:[e-mail]::Ll/dRbEb34Aev4xH:87If
X-Hashcash: 1:22:090730:[e-mail]::RG4y3HYxm/O/yrQE:aiV2
Date: Thu, 30 Jul 2009 12:10:26 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 29 Jul 2009 16:39:03 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Wed, Jul 29, 2009 at 11:21:11PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > Jeff Hutzelman points out that RFC2744 specifically requires that all
>> > gss_buffer_t outputs be released.  That wouldn't bother me at all here
>> > (we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
>> > RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
>> > chance to do that and didn't, so I'd say that these output buffers
>> > should be released by the app.
>> 
>> Good catch, I have removed the paragraph.  How memory should be managed
>> by applications (i.e., they have to be released) then follows directly
>> from the normative RFC 2744 and GS2 shouldn't say anything about it.
>> Alexey, I hope this resolves your question.
>
> It's useful for GS2 to remind the reader of the application's
> responsibility to release these buffers (RFC5587 will do just that).

RFC 2743 uses comments on the output variables, so I used the same, as
in:

   o sasl_mech_name UTF-8 STRING -- SASL name for this
     mechanism; caller must release with
     GSS_Release_buffer()

   o mech_name UTF-8 STRING -- name of this mechanism, possibly
     localized; caller must release with GSS_Release_buffer()

   o mech_description UTF-8 STRING -- possibly localized
     description of this mechanism; caller must release with
     GSS_Release_buffer()

/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 n6U9MdpG044245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2009 02:22:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6U9Md4K044244; Thu, 30 Jul 2009 02:22:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6U9MRBn044218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 30 Jul 2009 02:22:38 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n6U9MLZS005664; Thu, 30 Jul 2009 05:22:21 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n6U9MKux012281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jul 2009 05:22:20 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n6U9MKXG012174; Thu, 30 Jul 2009 05:22:20 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: SASL IETF75 summary
From: Tom Yu <[e-mail]>
Date: Thu, 30 Jul 2009 05:22:20 -0400
Message-ID: <[e-mail]>
Lines: 54
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simple Authentication And Security Layer (SASL)
IETF75, Stockholm, Sweden

Monday, July 27, 15:20--17:20
=============================

Chairs:

Tom Yu <[e-mail]>
Kurt Zeilenga <[e-mail]>

Scribe: Peter Saint-Andre

Jabber:
http://jabber.ietf.org/logs/sasl/2009-07-27.txt

Audio:
ftp://videolab.uoregon.edu/pub/videolab/media/ietf75/ietf75-mon-rm300-pm.mp3

Agenda slides:
http://www.ietf.org/proceedings/75/slides/sasl-0.pdf

GS2 slide:
http://www.ietf.org/proceedings/75/slides/sasl-1.pdf

====================

- draft-ietf-sasl-gs2-14 -- in WGLC
- draft-ietf-sasl-scram-02 -- in WGLC
- draft-ietf-sasl-4422bis-01 -- not much progress, mostly editorial
- changes
- draft-ietf-sasl-channel-bindings-03 -- some revisions, as side
  effect of SCRAM/GS2 discussion

SCRAM and GS2 in WGLC (concluding Aug. 3); mostly editorial comments
at this point.

SASL base spec to Draft Standard: need implementation report.  4422bis
needs revised SASLprep, which Kurt will work on.  Some discussion
about normative downref to SASLprep.  Probably not a problem because
individual mechanisms are what actually normatively reference it.

Drop EXTERNAL from base spec?  No consensus either way.  Probably not
a big deal; could possibly get folded into Simon's external-channel
draft.

Milestones:

Mar 09 GS2 WGLC -- in progress
Mar 09 SCRAM WGLC -- in progress
Apr 09 decide CRAM-MD5 approach -- done; Tom will summarize to list
Jun 09 4422bis I-D -- initial revisions
Oct 09 implementation report
Oct 09 4422bis WGLC



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TLngPC000605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 14:49:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TLngxd000604; Wed, 29 Jul 2009 14:49: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 n6TLnVR2000587 for <[e-mail]>; Wed, 29 Jul 2009 14:49:41 -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 n6TLnULw029090 for <[e-mail]>; Wed, 29 Jul 2009 21:49: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 n6TLnU4t036668 for <[e-mail]>; Wed, 29 Jul 2009 15:49: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 n6TLd3TF008618; Wed, 29 Jul 2009 16:39:03 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TLd3qA008617; Wed, 29 Jul 2009 16:39:03 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 16:39:03 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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, Jul 29, 2009 at 11:21:11PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > Jeff Hutzelman points out that RFC2744 specifically requires that all
> > gss_buffer_t outputs be released.  That wouldn't bother me at all here
> > (we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
> > RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
> > chance to do that and didn't, so I'd say that these output buffers
> > should be released by the app.
> 
> Good catch, I have removed the paragraph.  How memory should be managed
> by applications (i.e., they have to be released) then follows directly
> from the normative RFC 2744 and GS2 shouldn't say anything about it.
> Alexey, I hope this resolves your question.

It's useful for GS2 to remind the reader of the application's
responsibility to release these buffers (RFC5587 will do just that).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TLLRSU098759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 14:21:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TLLRxx098758; Wed, 29 Jul 2009 14:21: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 n6TLLECd098747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 14:21:26 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TLLBbP000587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 23:21:13 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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:090729:[e-mail]::Bdse7JcuZ4HsBDdo:4uU
X-Hashcash: 1:22:090729:[e-mail]::h0HrIrtxznDPrpFu:AOw7
X-Hashcash: 1:22:090729:[e-mail]::ulod3CrSDnTMJUSc:LYL0
Date: Wed, 29 Jul 2009 23:21:11 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 29 Jul 2009 15:52:10 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> Jeff Hutzelman points out that RFC2744 specifically requires that all
> gss_buffer_t outputs be released.  That wouldn't bother me at all here
> (we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
> RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
> chance to do that and didn't, so I'd say that these output buffers
> should be released by the app.

Good catch, I have removed the paragraph.  How memory should be managed
by applications (i.e., they have to be released) then follows directly
from the normative RFC 2744 and GS2 shouldn't say anything about it.
Alexey, I hope this resolves your question.

/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 n6TL2qEK097325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 14:02:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TL2qj9097324; Wed, 29 Jul 2009 14:02:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-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 n6TL2dYx097313 for <[e-mail]>; Wed, 29 Jul 2009 14:02: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 n6TL2dF3023686 for <[e-mail]>; Wed, 29 Jul 2009 21:02: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 n6TL2cmc003149 for <[e-mail]>; Wed, 29 Jul 2009 15:02:38 -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 n6TKqBP4008577; Wed, 29 Jul 2009 15:52:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TKqA3V008576; Wed, 29 Jul 2009 15:52:10 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 15:52:10 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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>

Jeff Hutzelman points out that RFC2744 specifically requires that all
gss_buffer_t outputs be released.  That wouldn't bother me at all here
(we'd have to say that draft-ietf-sasl-gs2 updates RFC2744), but,
RFC5587 (draft-ietf-kitten-extended-mech-inquiry, in AUTH48) had a
chance to do that and didn't, so I'd say that these output buffers
should be released by the app.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6THHJjC080967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 10:17:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6THHJ8l080965; Wed, 29 Jul 2009 10:17:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6THHILr080958 for <[e-mail]>; Wed, 29 Jul 2009 10:17:18 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Jul 2009 18:17:16 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 2009 19:17:14 +0200
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: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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=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>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
 [...]

>Is my proposal to add
>
>   The memory allocated for the output variables must not be released
>   by the application.
>
>OK?  (Note I changed "should" into "must" here.)
>
>My text takes care of guidance for application writers, which I think is
>more important.  What Nico wrote is guidance for GSS-API authors.  Text
>proposals welcome to add that welcome. ;)
>  
>
Your version is fine as well.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6THFnpk080862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 10:15:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6THFnuc080861; Wed, 29 Jul 2009 10:15:49 -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 n6THFjpf080854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 10:15:48 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6THFgYt026291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 19:15:44 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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:090729:[e-mail]::FbpujhnHQ7jHbQXn:1Dbt
X-Hashcash: 1:22:090729:[e-mail]::vp3a2nFrXbDDZD1a:0SBK
X-Hashcash: 1:22:090729:[e-mail]::axJSY5s9HvzQ9uTg:BFIx
Date: Wed, 29 Jul 2009 19:15:42 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 29 Jul 2009 10:51:32 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Wed, Jul 29, 2009 at 05:39:10PM +0200, Simon Josefsson wrote:
>> Is my proposal to add
>> 
>>    The memory allocated for the output variables must not be released
>>    by the application.
>> 
>> OK?  (Note I changed "should" into "must" here.)
>
> Capitalized?

Right, I'm now using that text with MUST NOT in my local copy [1].

/Simon

[1] Always available from
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.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 n6TG20cP074637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 09:02:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TG20Na074636; Wed, 29 Jul 2009 09:02: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-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 n6TG1xl2074627 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 29 Jul 2009 09:02:00 -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 n6TG1xBj025325 for <[e-mail]>; Wed, 29 Jul 2009 16:01:59 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6TG1xRE053892 for <[e-mail]>; Wed, 29 Jul 2009 10:01:59 -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 n6TFpWLK008274; Wed, 29 Jul 2009 10:51:32 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TFpWcx008273; Wed, 29 Jul 2009 10:51:32 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 10:51:32 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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, Jul 29, 2009 at 05:39:10PM +0200, Simon Josefsson wrote:
> Is my proposal to add
> 
>    The memory allocated for the output variables must not be released
>    by the application.
> 
> OK?  (Note I changed "should" into "must" here.)

Capitalized?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TFvU4B074122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:57:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFvUHu074121; Wed, 29 Jul 2009 08:57:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-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 n6TFvJuq074089 for <[e-mail]>; Wed, 29 Jul 2009 08:57:29 -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 n6TFvJpM025733 for <[e-mail]>; Wed, 29 Jul 2009 15:57:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6TFvJWJ049657 for <[e-mail]>; Wed, 29 Jul 2009 09:57: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 n6TFkpxb008268; Wed, 29 Jul 2009 10:46:52 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TFkpCo008267; Wed, 29 Jul 2009 10:46:51 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 10:46:51 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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 Wed, Jul 29, 2009 at 05:35:08PM +0200, Simon Josefsson wrote:
> The GS2 document could also say that applications needs to release
> memory for these output variables.  However, I think these three output
> variables would typically be stored in static storage and wouldn't need
> to be released.  We could clarify this.  How about adding
> 
>    The memory allocate for the output variables need not be released
>    by the application.
> 
> to the sections for new GSS-API interfaces?

That's exactly it: there's no need to release these outputs as they
should be constants, effectively.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TFh5MV073038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:43:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFh5Kf073037; Wed, 29 Jul 2009 08:43:05 -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 n6TFgsCH073022 for <[e-mail]>; Wed, 29 Jul 2009 08:43:05 -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 n6TFgs5n009748 for <[e-mail]>; Wed, 29 Jul 2009 15:42:54 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 n6TFgrIC038572 for <[e-mail]>; Wed, 29 Jul 2009 09:42:53 -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 n6TFWRoR008206; Wed, 29 Jul 2009 10:32:27 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TFWR1o008205; Wed, 29 Jul 2009 10:32:27 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 10:32:27 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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 Wed, Jul 29, 2009 at 05:29:35PM +0200, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Things that are constant-like don't need to be freed.  For example,
> >mechanism OIDs returned by GSS_Indicate_mechs(),
> >GSS_Inquire_sec_context(), ...
> >
> >The same should apply here to these three output arguments.
> >
> This is fine with me. I would recommend adding this to the document.

I'd say we must add it.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TFdFpx072742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:39:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFdFOp072741; Wed, 29 Jul 2009 08:39:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-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 n6TFdCcG072729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 08:39:14 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TFdAad023665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 17:39:11 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090729:[e-mail]::KhOZ+H0OFbC03u7B:4Zwh
X-Hashcash: 1:22:090729:[e-mail]::Gmz2ueSzkCfDBqy0:59kq
X-Hashcash: 1:22:090729:[e-mail]::845w26CSujLjxZPt:GT5v
Date: Wed, 29 Jul 2009 17:39:10 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Wed, 29 Jul 2009 17:29:35 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

>>>>Do the 3 output parameters need to be freed?
>>>>      
>>>>
>>>Not sure if this needs to be mentioned, I can't find much discussion in
>>>RFC 2743 on this.  Nico?
>>>    
>>>
>>Things that are constant-like don't need to be freed.  For example,
>>mechanism OIDs returned by GSS_Indicate_mechs(),
>>GSS_Inquire_sec_context(), ...
>>
>>The same should apply here to these three output arguments.
>>
>>Yes, that means that if an implementation were to malloc memory for
>>them, then it could only freed them when the shared object is unloaded
>>or the process exits.
>>  
>>
> This is fine with me. I would recommend adding this to the document.

Is my proposal to add

   The memory allocated for the output variables must not be released
   by the application.

OK?  (Note I changed "should" into "must" here.)

My text takes care of guidance for application writers, which I think is
more important.  What Nico wrote is guidance for GSS-API authors.  Text
proposals welcome to add that welcome. ;)

/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 n6TFZEQN072286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:35:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFZEsQ072285; Wed, 29 Jul 2009 08:35: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 n6TFZBwe072278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 08:35:13 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TFZ8qP023545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 17:35:10 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090729:[e-mail]::SoTEqhz8ZzMQ+1BD:1m4c
X-Hashcash: 1:22:090729:[e-mail]::uRIokLVoUaPhCZHC:BYm0
X-Hashcash: 1:22:090729:[e-mail]::K5ZSTgjKyroeIbxG:I14Z
Date: Wed, 29 Jul 2009 17:35:08 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 29 Jul 2009 10:08:53 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
>> Alexey Melnikov <[e-mail]> writes:
>> > 6).
>> >
>> >> 10.1.  gss_inquire_saslname_for_mech
>> >>
>> >>    The C binding for the GSS_Inquire_SASLname_for_mech call is as
>> >>    follows.
>> >>
>> >>       OM_uint32 gss_inquire_saslname_for_mech(
>> >>         OM_uint32     *minor_status,
>> >>         const gss_OID  desired_mech,
>> >>         gss_buffer_t   sasl_mech_name,
>> >>         gss_buffer_t   mech_name,
>> >>         gss_buffer_t   mech_description,
>> >
>> > Do the 3 output parameters need to be freed?
>> 
>> Not sure if this needs to be mentioned, I can't find much discussion in
>> RFC 2743 on this.  Nico?
>
> Things that are constant-like don't need to be freed.  For example,
> mechanism OIDs returned by GSS_Indicate_mechs(),
> GSS_Inquire_sec_context(), ...
>
> The same should apply here to these three output arguments.
>
> Yes, that means that if an implementation were to malloc memory for
> them, then it could only freed them when the shared object is unloaded
> or the process exits.

The GS2 document could also say that applications needs to release
memory for these output variables.  However, I think these three output
variables would typically be stored in static storage and wouldn't need
to be released.  We could clarify this.  How about adding

   The memory allocate for the output variables need not be released
   by the application.

to the sections for new GSS-API interfaces?

/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 n6TFUQZr071624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:30:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFUQbI071623; Wed, 29 Jul 2009 08:30: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 n6TFU9fN071597 for <[e-mail]>; Wed, 29 Jul 2009 08:30:25 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Jul 2009 16:29:59 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 2009 17:29:35 +0200
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]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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 Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
>  
>
>>Alexey Melnikov <[e-mail]> writes:
>>    
>>
>>>6).
>>>      
>>>
>>>>10.1.  gss_inquire_saslname_for_mech
>>>>
>>>>   The C binding for the GSS_Inquire_SASLname_for_mech call is as
>>>>   follows.
>>>>
>>>>      OM_uint32 gss_inquire_saslname_for_mech(
>>>>        OM_uint32     *minor_status,
>>>>        const gss_OID  desired_mech,
>>>>        gss_buffer_t   sasl_mech_name,
>>>>        gss_buffer_t   mech_name,
>>>>        gss_buffer_t   mech_description,
>>>>        
>>>>
>>>Do the 3 output parameters need to be freed?
>>>      
>>>
>>Not sure if this needs to be mentioned, I can't find much discussion in
>>RFC 2743 on this.  Nico?
>>    
>>
>Things that are constant-like don't need to be freed.  For example,
>mechanism OIDs returned by GSS_Indicate_mechs(),
>GSS_Inquire_sec_context(), ...
>
>The same should apply here to these three output arguments.
>
>Yes, that means that if an implementation were to malloc memory for
>them, then it could only freed them when the shared object is unloaded
>or the process exits.
>  
>
This is fine with me. I would recommend adding this to the document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TFQZUD071218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:26:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFQZDa071217; Wed, 29 Jul 2009 08:26:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n6TFQMIk071175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 08:26:34 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TFQH0O023361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 17:26:20 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090729:[e-mail]::V4E7GGaV+AKgoXsm:4XQA
X-Hashcash: 1:22:090729:[e-mail]::0UQQAoTQiBAUZx2q:HP3P
X-Hashcash: 1:22:090729:[e-mail]::iVGCYwH85YADpEuL:FQBs
Date: Wed, 29 Jul 2009 17:26:16 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 29 Jul 2009 10:05:26 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
>> > 5). Section 9 says:
>> >
>> >   There's no requirement that any particular GSS-API name-types be
>> >   used.  However, typically SASL servers will have host-based acceptor
>> >   principal names (see [RFC2743] section 4.1) and clients will
>> >   typically have username initiator principal names (see [RFC2743]
>> >   section 4.2).
>> >
>> > This might be trivial, but I am missing the following text from RFC 4752:
>> >   ... targ_name equal to output_name from GSS_Import_Name called with
>> > input_name_type
>> >   of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
>> >   "service@hostname" where "service" is the service name specified in
>> >   the protocol's profile, and "hostname" is the fully qualified host
>> >   name of the server.
>> >
>> > So possibly reword this paragraph to read:
>> >
>> >   There's no requirement that any particular GSS-API name-types be
>> >   used.  However, typically SASL servers will have host-based acceptor
>> >   principal names (see [RFC2743] section 4.1) and clients will
>> >   typically have username initiator principal names (see [RFC2743]
>> >   section 4.2). When a host-based acceptor principal name is used
>> >   ("service@hostname"), "service" is the service name specified in
>> >   the protocol's profile, and "hostname" is the fully qualified host
>> >   name of the server.
>> >
>> > ?
>> 
>> Nico?
>
> Fine with me.

Great, I've changed my local copy.

/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 n6TFJM7S070692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:19:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFJMT0070691; Wed, 29 Jul 2009 08:19:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TFJLrs070684 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 29 Jul 2009 08:19:22 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6TFJLpU026430 for <[e-mail]>; Wed, 29 Jul 2009 15:19: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 n6TFJLB1021688 for <[e-mail]>; Wed, 29 Jul 2009 09:19: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 n6TF8rgf008174; Wed, 29 Jul 2009 10:08:53 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TF8rNS008173; Wed, 29 Jul 2009 10:08:53 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 10:08:53 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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 Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
> Alexey Melnikov <[e-mail]> writes:
> > 6).
> >
> >> 10.1.  gss_inquire_saslname_for_mech
> >>
> >>    The C binding for the GSS_Inquire_SASLname_for_mech call is as
> >>    follows.
> >>
> >>       OM_uint32 gss_inquire_saslname_for_mech(
> >>         OM_uint32     *minor_status,
> >>         const gss_OID  desired_mech,
> >>         gss_buffer_t   sasl_mech_name,
> >>         gss_buffer_t   mech_name,
> >>         gss_buffer_t   mech_description,
> >
> > Do the 3 output parameters need to be freed?
> 
> Not sure if this needs to be mentioned, I can't find much discussion in
> RFC 2743 on this.  Nico?

Things that are constant-like don't need to be freed.  For example,
mechanism OIDs returned by GSS_Indicate_mechs(),
GSS_Inquire_sec_context(), ...

The same should apply here to these three output arguments.

Yes, that means that if an implementation were to malloc memory for
them, then it could only freed them when the shared object is unloaded
or the process exits.

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 n6TFG8eK070514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:16:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFG8Rn070513; Wed, 29 Jul 2009 08:16: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-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 n6TFFt3o070495 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 29 Jul 2009 08:16:05 -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 n6TFFsSS025426 for <[e-mail]>; Wed, 29 Jul 2009 15:15:54 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 n6TFFsML018803 for <[e-mail]>; Wed, 29 Jul 2009 09:15:54 -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 n6TF5QTI008166; Wed, 29 Jul 2009 10:05:26 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TF5QKq008165; Wed, 29 Jul 2009 10:05:26 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 10:05:26 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
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 Mon, Jul 27, 2009 at 03:43:20PM +0200, Simon Josefsson wrote:
> > 5). Section 9 says:
> >
> >   There's no requirement that any particular GSS-API name-types be
> >   used.  However, typically SASL servers will have host-based acceptor
> >   principal names (see [RFC2743] section 4.1) and clients will
> >   typically have username initiator principal names (see [RFC2743]
> >   section 4.2).
> >
> > This might be trivial, but I am missing the following text from RFC 4752:
> >   ... targ_name equal to output_name from GSS_Import_Name called with
> > input_name_type
> >   of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
> >   "service@hostname" where "service" is the service name specified in
> >   the protocol's profile, and "hostname" is the fully qualified host
> >   name of the server.
> >
> > So possibly reword this paragraph to read:
> >
> >   There's no requirement that any particular GSS-API name-types be
> >   used.  However, typically SASL servers will have host-based acceptor
> >   principal names (see [RFC2743] section 4.1) and clients will
> >   typically have username initiator principal names (see [RFC2743]
> >   section 4.2). When a host-based acceptor principal name is used
> >   ("service@hostname"), "service" is the service name specified in
> >   the protocol's profile, and "hostname" is the fully qualified host
> >   name of the server.
> >
> > ?
> 
> Nico?

Fine with me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TFDtiN070291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 08:13:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TFDsWx070290; Wed, 29 Jul 2009 08:13: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 n6TFDgLm070250 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 29 Jul 2009 08:13: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 n6TFDg9w011662 for <[e-mail]>; Wed, 29 Jul 2009 15:13: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 n6TFDgeH016726 for <[e-mail]>; Wed, 29 Jul 2009 09:13: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 n6TF3Ej0008160; Wed, 29 Jul 2009 10:03:14 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6TF3Cd9008159; Wed, 29 Jul 2009 10:03:12 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 29 Jul 2009 10:03:12 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Peter Saint-Andre <[e-mail]>, Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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, Jul 29, 2009 at 01:40:39PM +0200, Alexey Melnikov wrote:
> 
> Alexey Melnikov wrote:
> 
> >Peter Saint-Andre wrote:
> >
> >>On 7/28/09 1:09 PM, Alexey Melnikov wrote:
> >>I must say that point to the IANA registration as the definitive
> >>reference for tls-unique confused me, since it is not a specification.
> >>If we could somehow include a reference to the I-D, I think that we
> >>could avoid confusing some implementers.
> >
> >The reference includes the whole definition.
> >If the draft describing this in more details is published, I would 
> >have no problems referencing it.
> 
> >But as I said earlier, I would rather not block on this extra document.
> 
> Having said that, I am Ok with adding an informative reference.

The I-D in question ought to progress very quickly, one would think.
I should ask an AD to shepherd it.  I will.

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 n6TCDUGb054436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 05:13:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TCDUaD054435; Wed, 29 Jul 2009 05:13: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 n6TCDR1A054428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 05:13:28 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-52e8.meeting.ietf.org [130.129.82.232] (may be forged)) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TCDNxs017644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 14:13:25 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090729:[e-mail]::67Uv2G8LQeuIeLJV:1bq5
X-Hashcash: 1:22:090729:[e-mail]::j/H9GkRbW0VY8Pqh:mIk/
X-Hashcash: 1:22:090729:[e-mail]::W9U7afQxpqmaipYK:nwPd
Date: Wed, 29 Jul 2009 14:13:23 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 8 Jul 2009 10:46:13 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

>> In Section 5.1:
>> 
>> >   The application-data field MUST be set to the gs2-header concatenated
>> >   with, when a gs2-cb-flag of "p" is used, the application's channel
>> >   binding data (if any).
>> 
>> I think "(if any)" should be removed, because for "p" the channel 
>> binding data is always present. I assume that a channel binding data 
>> can't be the empty string.
>
> Sure.

I have removed this in my local copy.

/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 n6TBxaa6053156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 04:59:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TBxaVt053155; Wed, 29 Jul 2009 04:59:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBxXNZ053148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 04:59:35 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-52e8.meeting.ietf.org [130.129.82.232] (may be forged)) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TBxTAF017239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 13:59:31 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Peter Saint-Andre <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-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:090729:[e-mail]::UyvdaM45ZNMEgeME:dxR
X-Hashcash: 1:22:090729:[e-mail]::i7qzZrHRcgY/oIZZ:BjMY
X-Hashcash: 1:22:090729:[e-mail]::DWMP3xsrBgJfZbWb:pOze
X-Hashcash: 1:22:090729:[e-mail]::ruOQKQo93HcD0act:V3c/
Date: Wed, 29 Jul 2009 13:59:29 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Wed, 29 Jul 2009 13:40:39 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Alexey Melnikov wrote:
>
>> Peter Saint-Andre wrote:
>>
>>> On 7/28/09 1:09 PM, Alexey Melnikov wrote:
>>> I must say that point to the IANA registration as the definitive
>>> reference for tls-unique confused me, since it is not a specification.
>>> If we could somehow include a reference to the I-D, I think that we
>>> could avoid confusing some implementers.
>>
>> The reference includes the whole definition.
>> If the draft describing this in more details is published, I would
>> have no problems referencing it.
>
>> But as I said earlier, I would rather not block on this extra document.
>
> Having said that, I am Ok with adding an informative reference.

I've done this to GS2, i.e., add normative reference to IANA
registration and informative reference to
I-D.altman-tls-channel-bindings, both cited at the same place in the
document.

/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 n6TBwW5o052675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 04:58:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TBwWkF052674; Wed, 29 Jul 2009 04:58:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stpeter.im (stpeter.im [207.210.219.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBwUkf052666 for <[e-mail]>; Wed, 29 Jul 2009 04:58:31 -0700 (MST) (envelope-from [e-mail])
Received: from squire.local (unknown [212.112.167.85]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B1AF4007B; Wed, 29 Jul 2009 05:58:30 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 2009 13:58:28 +0200
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Tom Yu <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/09 4:17 AM, Tom Yu wrote:
> This message commences a WG Last Call on the following Internet-Draft:
> 
> 	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
> 	Author(s)       : A. Menon-Sen, et al.
> 	Filename        : draft-ietf-sasl-scram-02.txt
> 	Pages           : 33
> 	Date            : 2009-07-08
> 
> This Last Call will expire on 03 August 2009.  This document is
> intended for the Standards Track.  Please review this document and
> send technical feedback to the WG mailing list, and editorial comments
> to the authors.

Some nits...

SECTION 2

Typo: "family of mechanism" => "family of mechanisms"

The second paragraph references security layers, which are not
previously defined (and no reference is made to RFC 5056 here).

Under protocol features, the document says that "A standard attribute is
defined to enable storage of the authentication information in LDAPv3"
but I don't see where this attribute is defined in the spec.

SECTION 3

The specification assumes that "the client is in possession of a
username and password"; does it make sense to mention the fact that
passwordless login can occur in this world (Kerb, X.509, etc.)?

SECTION 4

Typo: "hashed function" => "hash function"

I think the following text is slightly ambiguous:

   The "-PLUS" suffix is used only when the server supports channel
   binding to the external channel.  In this case the server will
   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
   negotiation of the use of channel binding.  See Section 6.

This could be read to mean that if a server does not support channel
bindings, then it will advertise only all and only SCRAM-SHA-1 (but
never, say, SCRAM-SHA-256). I think we mean that if a server does not
support channel bindings, then it will advertise only mechanisms of the
form SCRAM-SHA-length and never mechanisms of the form
SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
other than SHA-1).

SECTION 5

There is an example of "tls-server-end-point" but no reference for this
channel binding type.

SECTION 5.1

For the definition of "n", the text says that "a client must include it
in its first message to the server"; do we mean MUST here?

The "n" attribute specifies a username. Is it up to the using protocol
define exactly what a username is? I am thinking of hosting providers
that might host multiple domains for a given service, such that the the
username is not a "local-part" but could include a domain name (XMPP is
but one example; others might include IMAP).

For the "n" attribute, "the server SHOULD prepare it using the
"SASLPrep" profile". Under what circumstances is it appropriate for the
server to not prepare the value according to SASLPrep?

Typo: "It is important that this be value" => "It is important that this
value be"

Typo: missing close paren after the reference to RFC 5056

For the "i" attribute, the text says that it "must be sent by the server
along with the user's salt"; do we mean MUST here?

SECTION 6

Typo: "MUST chose" => "MUST choose"

SECTION 8.2

Typo: "SHALL BE" => "SHALL be"

APPENDIX A

CRAM-MD5 is mentioned as another authentication mechanism, seemingly
with the meaning that SCRAM is intended to obsolete CRAM-MD5. I recall
an objection by John Klensin at the mic in San Francisco that in fact
SCRAM is intended to obsolete DIGEST-MD5 but not CRAM-MD5. But perhaps
that is a matter for draft-ietf-sasl-crammd5-to-historic, not this
specification.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpwOWQACgkQNL8k5A2w/vz7DQCgnMe2cKkgYMVDpr2ASq12qZtq
HmIAoIfo0DVjeOLyJkZvVnc7UsCxa+f9
=smy1
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBmJmX051545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 04:48:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TBmJnf051544; Wed, 29 Jul 2009 04:48:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBmGbZ051536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 04:48:18 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-52e8.meeting.ietf.org [130.129.82.232] (may be forged)) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TBmC1W016930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 13:48:15 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090729:[e-mail]::xLltynpjUHMFsNOC:ql4
X-Hashcash: 1:22:090729:[e-mail]::ALNmYDIof6y3gPdc:3ZVc
X-Hashcash: 1:22:090729:[e-mail]::tyPzpbw3i3azJK6q:4tyz
Date: Wed, 29 Jul 2009 13:48:12 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Wed, 08 Jul 2009 17:31:53 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Nicolas Williams wrote:
>
>>On Wed, Jul 08, 2009 at 01:11:57PM +0100, Alexey Melnikov wrote:
>>  
>>
>>>Some quick comments.
>>>
>>>In Section 3.5:
>>>    
>>>
>>>>  If the client negotiates mechanisms then clients MUST select the
>>>>  PLUS-variant if offered by the server.
>>>>      
>>>>
>>>This make sense.
>>>    
>>>
>>>>Otherwise, if the client does
>>>>  not negotiate mechanisms then it MUST use the non-PLUS variant.
>>>>      
>>>>
>>> This doesn't make much sense. If the client remembers what the
>>> server advertised previously, then it can just use the same
>>> mechanism.
>>> But even if the client never negotiate mechanisms (e.g. if the user
>>> selected the mechanism in UI), then why should it be restricted to
>>> non-PLUS variant?
>>>    
>>>
>>I think that text had been intended to say that the non-PLUS variant
>>must be selected when the client has no idea what the server supports
>>and the client isn't using CB.  But it doesn't really matter.  I'd be
>>happy with removing this text.
>>  
>>
> Alternatively I suggest correcting the text to read something like this:
>
>    Otherwise (the client does not negotiate mechanisms),
>    if the client has no prior knowledge about mechanisms supported
>    by the server and wasn't explicitly configured to use a particular
>    variant of the GS2 mechanism, then it MUST select
>    only non-PLUS version of the GS2 mechanism.

Works fine with me.  I have made this change in my local copy.

/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 n6TBgQrq051184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 04:42:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TBgQta051183; Wed, 29 Jul 2009 04:42:26 -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 n6TBgNcX051174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 04:42:25 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-52e8.meeting.ietf.org [130.129.82.232] (may be forged)) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6TBgLGv016791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 13:42:22 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090729:[e-mail]::p3O42SxtYdH/yMZW:0Jf9
X-Hashcash: 1:22:090729:[e-mail]::+nnCt5tu920BHvqu:VkFD
Date: Wed, 29 Jul 2009 13:42:20 +0200
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Mon, 27 Jul 2009 15:43:20 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson <[e-mail]> writes:

>> Note that SCRAM also says:
>>
>> , or if the client wishes to use channel
>>            binding but the client does not negotiate
>>            mechanisms
>>
>>
>>   use a "p" gs2-cb-flag to indicate the channel binding type it is
>>   using.
>
> Should this be added?  I'm not sure.

After re-reading the relevant text again, I think it should be added.
Done in my copy.

/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 n6TBer7M051102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 04:40:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TBerh1051101; Wed, 29 Jul 2009 04:40:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBepX9051092 for <[e-mail]>; Wed, 29 Jul 2009 04:40:52 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Jul 2009 12:40:49 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 2009 13:40:39 +0200
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: Peter Saint-Andre <[e-mail]>
CC: Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Peter Saint-Andre wrote:
>
>> On 7/28/09 1:09 PM, Alexey Melnikov wrote:
>> I must say that point to the IANA registration as the definitive
>> reference for tls-unique confused me, since it is not a specification.
>> If we could somehow include a reference to the I-D, I think that we
>> could avoid confusing some implementers.
>
> The reference includes the whole definition.
> If the draft describing this in more details is published, I would 
> have no problems referencing it.

> But as I said earlier, I would rather not block on this extra document.

Having said that, I am Ok with adding an informative reference.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBbW0s050868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 04:37:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TBbWIK050867; Wed, 29 Jul 2009 04:37:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBbKHQ050853 for <[e-mail]>; Wed, 29 Jul 2009 04:37:31 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 29 Jul 2009 12:37:17 +0100
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 2009 13:37:00 +0200
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: Peter Saint-Andre <[e-mail]>
CC: Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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=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>

Peter Saint-Andre wrote:

>On 7/28/09 1:09 PM, Alexey Melnikov wrote:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>Alexey Melnikov <[e-mail]> writes:
>>>      
>>>
>>>>Simon Josefsson wrote:  
>>>>        
>>>>
>>>>>Regarding
>>>>>
>>>>> [tls-unique]
>>>>>            Zhu, L., "Registration of TLS unique channel binding
>>>>>            (generic)", IANA http://www.iana.org/assignments/
>>>>>            channel-binding-types/tls-unique, July 2008.
>>>>>
>>>>>I think we should replace that with a reference to
>>>>>
>>>>>http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
>>>>>          
>>>>>
>>>>This would mean a new normative reference and would delay publication
>>>>of both documents.
>>>>While I think it would be nice to use this reference, I am against
>>>>blocking SCRAM and GS2 on this.
>>>>        
>>>>
>>>OK, I'm fine with that -- it will mean a downref (right?), and I assumed
>>>those causes other sorts of problems that could be avoided.
>>>      
>>>
>>I am not entirely sure if it is. But I don't think it will be
>>problematic with IESG, even if it.
>>    
>>
>I must say that point to the IANA registration as the definitive
>reference for tls-unique confused me, since it is not a specification.
>If we could somehow include a reference to the I-D, I think that we
>could avoid confusing some implementers.
>  
>
The reference includes the whole definition.
If the draft describing this in more details is published, I would have 
no problems referencing it.

But as I said earlier, I would rather not block on this extra document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBWKkx050456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 04:32:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TBWK7n050454; Wed, 29 Jul 2009 04:32:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stpeter.im (stpeter.im [207.210.219.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TBW9mH050428 for <[e-mail]>; Wed, 29 Jul 2009 04:32:19 -0700 (MST) (envelope-from [e-mail])
Received: from squire.local (unknown [212.112.167.85]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CF3154007B; Wed, 29 Jul 2009 05:32:07 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 2009 13:31:51 +0200
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/28/09 1:09 PM, Alexey Melnikov wrote:
> 
> Simon Josefsson wrote:
> 
>> Alexey Melnikov <[e-mail]> writes:
>>  
>>
>>> Simon Josefsson wrote:
>>>   
>>>> Regarding
>>>>
>>>>  [tls-unique]
>>>>             Zhu, L., "Registration of TLS unique channel binding
>>>>             (generic)", IANA http://www.iana.org/assignments/
>>>>             channel-binding-types/tls-unique, July 2008.
>>>>
>>>> I think we should replace that with a reference to
>>>>
>>>> http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
>>>>     
>>> This would mean a new normative reference and would delay publication
>>> of both documents.
>>> While I think it would be nice to use this reference, I am against
>>> blocking SCRAM and GS2 on this.
>>>   
>> OK, I'm fine with that -- it will mean a downref (right?), and I assumed
>> those causes other sorts of problems that could be avoided.
>>  
>>
> I am not entirely sure if it is. But I don't think it will be
> problematic with IESG, even if it.

I must say that point to the IANA registration as the definitive
reference for tls-unique confused me, since it is not a specification.
If we could somehow include a reference to the I-D, I think that we
could avoid confusing some implementers.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpwMycACgkQNL8k5A2w/vzcvgCg4QV/fd2jSX9FBaSZovajeNa2
2EQAoLHi6kw6sxr9W9DmAXzX3tdoC9II
=JB8w
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6T9JieC038297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 02:19:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6T9JiJw038296; Wed, 29 Jul 2009 02:19: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 n6T9JUQq038276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 29 Jul 2009 02:19:42 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6T9JLK4012627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Jul 2009 11:19:24 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]> <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090729:[e-mail]::JiI36IaXZjOp+vKD:62tG
X-Hashcash: 1:22:090729:[e-mail]::qzzpoiwq67rvPXwo:6ZE9
X-Hashcash: 1:22:090729:[e-mail]::ZYwcY1qWEEY7/42s:ClfB
X-Hashcash: 1:22:090729:[e-mail]::oYr90BPf3vrPdt7F:AX6k
Date: Wed, 29 Jul 2009 11:19:21 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 28 Jul 2009 16:43:38 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Jul 28, 2009 at 11:23:20PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > I'll be happy to see this SHOULD turn into a MUST.
>> 
>> The last sentence still seems necessary though.  So the paragraph
>> becomes:
>> 
>>   Clients MUST choose the tls-unique channel binding type.  Servers MUST
>>   choose the channel binding type indicated by the client, if they
>>   support it.
>> 
>> I suspect we want SCRAM and GS2 to be consistent on this, right?  So
>> both documents needs this change.
>
> Yes.
>
> Also, we should allow application protocols to specify a different CB
> type.
>
>    Clients MUST choose the default channel binding type for the
>    application -- 'tls-unique' for any applications that don't specify
>    one.  Servers MUST choose the channel binding type indicated by the
>    client, or fail authentication if they don't support it.

Works for me.  Chris, Alexey, others, are you OK with that text?  I'll
update my copy of GS2 to use it if we all agree on this text.

/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 n6SM1m4J094429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 15:01:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SM1m3v094427; Tue, 28 Jul 2009 15:01:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-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 n6SM1bZl094408 for <[e-mail]>; Tue, 28 Jul 2009 15:01:48 -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 n6SM1ba6021481 for <[e-mail]>; Tue, 28 Jul 2009 22:01: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 n6SM1bPW030976 for <[e-mail]>; Tue, 28 Jul 2009 16:01: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 n6SLhdsk007693; Tue, 28 Jul 2009 16:43:39 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6SLhcA0007692; Tue, 28 Jul 2009 16:43:38 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 28 Jul 2009 16:43:38 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Message-ID: <[e-mail]>
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]> <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 28, 2009 at 11:23:20PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > I'll be happy to see this SHOULD turn into a MUST.
> 
> The last sentence still seems necessary though.  So the paragraph
> becomes:
> 
>   Clients MUST choose the tls-unique channel binding type.  Servers MUST
>   choose the channel binding type indicated by the client, if they
>   support it.
> 
> I suspect we want SCRAM and GS2 to be consistent on this, right?  So
> both documents needs this change.

Yes.

Also, we should allow application protocols to specify a different CB
type.

   Clients MUST choose the default channel binding type for the
   application -- 'tls-unique' for any applications that don't specify
   one.  Servers MUST choose the channel binding type indicated by the
   client, or fail authentication if they don't support 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 n6SLNhSd092305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 14:23:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SLNhAO092304; Tue, 28 Jul 2009 14:23: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 n6SLNUe0092284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 14:23:42 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6SLNKTw021438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 23:23:22 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]> <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::QBaIREtbd0p/ws1h:2h1S
X-Hashcash: 1:22:090728:[e-mail]::G6nHaQOIH6M0vEtk:5e0x
X-Hashcash: 1:22:090728:[e-mail]::zxV49JuMKAfR0Ht0:EupN
X-Hashcash: 1:22:090728:[e-mail]::LAiHjqCnuPRHDi4D:I5va
Date: Tue, 28 Jul 2009 23:23:20 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 28 Jul 2009 11:14:48 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Jul 28, 2009 at 02:30:39PM +0200, Simon Josefsson wrote:
>> Chris Newman <[e-mail]> writes:
>> > Now that you've goaded me to explain my concern.  I'll make a concrete
>> > suggestion to improve the SCRAM channel bindings section.  I suggest
>> > we replace this text:
>> >
>> >   Clients SHOULD choose the tls-unique channel binding type.
>> >   Conversely, clients MAY choose a different channel binding type based
>> >   on user input, configuration, or a future, as-yet undefined channel
>> >   binding type negotiation protocol.  Servers MUST choose the channel
>> >   binding type indicated by the client, if they support it.
>> >
>> > with:
>> >
>> >   Clients MUST use the tls-unique channel binding type if a TLS channel is
>> >   active when SCRAM is used.  Clients MAY use a different channel
>> > binding type if
>> >   an as-yet undefined channel binding type negotiation has confirmed
>> > the server
>> >   supports the channel-binding type the client selects.
>> >
>> > This way, SCRAM+TLS-channel-bindings will interoperate.  With the
>> > current vague text, it's possible for a compliant client's SCRAM
>> > implementation to fail to interoperate when communicating with a
>> > compliant server's SCRAM + TLS-channel-bindings implementation.
>> 
>> I'm not sure this change is good -- first, the MUST is clearly violated
>> when the MAY-path is exercised, so it is not internally consistent.
>
> We do this all the time in IETF protocols, where we say that one MUST
> send 0 in some field that's reserved for future extensions, and we state
> how one must react to non-zero values in that field, then later we relax
> that and say what values may be sent.  What should happen here is that
> the second sentence in Chris' proposed text should just be removed -- a
> future update will not be bound to keep the MUST in the first sentence.

Right.

>> This was one of the motivations for SHOULD, IIRC, although I agree that
>> it wasn't completely clear before either.  Also you dropped the last
>> sentence which is necessary to get interoperability.  How about:
>
> No, _my_ motivation for that SHOULD was to allow clients and servers to
> agree a priori and out of band to use some other CB type than
> tls-unique.

That is what I meant too.

> I'll be happy to see this SHOULD turn into a MUST.

The last sentence still seems necessary though.  So the paragraph
becomes:

  Clients MUST choose the tls-unique channel binding type.  Servers MUST
  choose the channel binding type indicated by the client, if they
  support it.

I suspect we want SCRAM and GS2 to be consistent on this, right?  So
both documents needs this change.

/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 n6SGWj5f070960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 09:32:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SGWjgX070959; Tue, 28 Jul 2009 09:32:45 -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 n6SGWicu070953 for <[e-mail]>; Tue, 28 Jul 2009 09:32:44 -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 n6SGWina018628 for <[e-mail]>; Tue, 28 Jul 2009 16:32:44 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 n6SGWhQ7035849 for <[e-mail]>; Tue, 28 Jul 2009 10:32: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 n6SGEmWa007489; Tue, 28 Jul 2009 11:14:48 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6SGEm3v007488; Tue, 28 Jul 2009 11:14:48 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 28 Jul 2009 11:14:48 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Message-ID: <[e-mail]>
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]> <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 28, 2009 at 02:30:39PM +0200, Simon Josefsson wrote:
> Chris Newman <[e-mail]> writes:
> > Now that you've goaded me to explain my concern.  I'll make a concrete
> > suggestion to improve the SCRAM channel bindings section.  I suggest
> > we replace this text:
> >
> >   Clients SHOULD choose the tls-unique channel binding type.
> >   Conversely, clients MAY choose a different channel binding type based
> >   on user input, configuration, or a future, as-yet undefined channel
> >   binding type negotiation protocol.  Servers MUST choose the channel
> >   binding type indicated by the client, if they support it.
> >
> > with:
> >
> >   Clients MUST use the tls-unique channel binding type if a TLS channel is
> >   active when SCRAM is used.  Clients MAY use a different channel
> > binding type if
> >   an as-yet undefined channel binding type negotiation has confirmed
> > the server
> >   supports the channel-binding type the client selects.
> >
> > This way, SCRAM+TLS-channel-bindings will interoperate.  With the
> > current vague text, it's possible for a compliant client's SCRAM
> > implementation to fail to interoperate when communicating with a
> > compliant server's SCRAM + TLS-channel-bindings implementation.
> 
> I'm not sure this change is good -- first, the MUST is clearly violated
> when the MAY-path is exercised, so it is not internally consistent.

We do this all the time in IETF protocols, where we say that one MUST
send 0 in some field that's reserved for future extensions, and we state
how one must react to non-zero values in that field, then later we relax
that and say what values may be sent.  What should happen here is that
the second sentence in Chris' proposed text should just be removed -- a
future update will not be bound to keep the MUST in the first sentence.

> This was one of the motivations for SHOULD, IIRC, although I agree that
> it wasn't completely clear before either.  Also you dropped the last
> sentence which is necessary to get interoperability.  How about:

No, _my_ motivation for that SHOULD was to allow clients and servers to
agree a priori and out of band to use some other CB type than
tls-unique.  I'll be happy to see this SHOULD turn into a MUST.

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 n6SGUoBh070807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 09:30:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SGUoRU070806; Tue, 28 Jul 2009 09:30:50 -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 n6SGUcZi070788 for <[e-mail]>; Tue, 28 Jul 2009 09:30:49 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <Sm8nrAAssGl=@rufus.isode.com>; Tue, 28 Jul 2009 17:30:37 +0100
Message-ID: <[e-mail]>
Date: Tue, 28 Jul 2009 18:30:24 +0200
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: Jeffrey Hutzelman <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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:

>Jeffrey Hutzelman <[e-mail]> writes:
>  
>
>>--On Tuesday, July 28, 2009 11:05:26 AM +0200 Simon Josefsson
>><[e-mail]> wrote:
>>    
>>
>>>The IANA section says:
>>>
>>>   IANA is requested to prevent future registrations of SASL mechanisms
>>>   starting with SCRAM- without consulting the SASL mailing list
>>>   <[e-mail]> first.
>>>
>>>I'm not sure how the IANA would parse this request.  Who on this list
>>>has authority to say yes or no to IANA?  For clarity, I think we should
>>>use one of the terms defined by RFC 2434.  Is this IETF Consensus?  Or
>>>Expert Review?  Or Standards Action?
>>>      
>>>
>>I'm pretty sure it's Expert Review with a mailing list as the expert.
>>    
>>
>I see.  I didn't know an open mailing list could be a Designated Expert.
>  
>
I haven't heard of such cases either: somebody has to be a gatekeeper.

>>But given the agreement we seemed to have during yesterday's meeting
>>that this family should have slow growth accommodating only successor
>>hashes, I think Standards Action would be more appropriate.
>>    
>>
>Works fine with me.
>  
>
Works for me as well.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SGSv0C070501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 09:28:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SGSvAj070500; Tue, 28 Jul 2009 09:28: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 n6SGSk8f070481 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 28 Jul 2009 09:28:57 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SGSkjq001297 for <[e-mail]>; Tue, 28 Jul 2009 16:28:46 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6SGSk8l031820 for <[e-mail]>; Tue, 28 Jul 2009 10:28:46 -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 n6SGAoiM007481; Tue, 28 Jul 2009 11:10:50 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6SGAmA9007480; Tue, 28 Jul 2009 11:10:48 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 28 Jul 2009 11:10:48 -0500
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Message-ID: <[e-mail]>
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]> <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 28, 2009 at 02:11:45PM +0200, Chris Newman wrote:
>          ...  All this talk of channel binding negotiation is leading in 
> the direction of non-interoperability and is risking the possibility of 
> success with option 3.  ...

There was an unfortunately long thread on that topic.  The consensus
that we reached was that we'd NOT bother with channel binding type
negotiation for now.

I chatted with you and found that your concern is primarily about the
fact that we say that the client SHOULD, not MUST, use tls-unique.  I'm
willing to tighten this to a MUST.

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 n6SGBorF068888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 09:11:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SGBoFb068887; Tue, 28 Jul 2009 09:11:50 -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 n6SGBdEa068859 for <[e-mail]>; Tue, 28 Jul 2009 09:11:49 -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 n6SGBdVP009091 for <[e-mail]>; Tue, 28 Jul 2009 16:11: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 n6SGBcu8015952 for <[e-mail]>; Tue, 28 Jul 2009 10:11:38 -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 n6SG1BpA007471; Tue, 28 Jul 2009 11:01:11 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6SG1Bfx007470; Tue, 28 Jul 2009 11:01:11 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 28 Jul 2009 11:01:11 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-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, Jul 28, 2009 at 12:44:13PM +0200, Simon Josefsson wrote:
> Alexey Melnikov <[e-mail]> writes:
> > Simon Josefsson wrote:
> >>   [tls-unique]
> >>              Zhu, L., "Registration of TLS unique channel binding
> >>              (generic)", IANA http://www.iana.org/assignments/
> >>              channel-binding-types/tls-unique, July 2008.
> >>
> >>I think we should replace that with a reference to
> >>
> >>http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
> >>
> > This would mean a new normative reference and would delay publication
> > of both documents.
> > While I think it would be nice to use this reference, I am against
> > blocking SCRAM and GS2 on this.
> 
> OK, I'm fine with that -- it will mean a downref (right?), and I assumed
> those causes other sorts of problems that could be avoided.

You know, since the registration exists already, it's possible that the
downref could be allowed at publication time.

Or, better yet, how about:

 - have a normative reference to [tls-unique] as in the I-D right now

and

 - have an informative reference to draft-altman-tls-channel-bindings.

A creative idea, maybe too creative :)

But at least readers will be able to find whatever RFC number
draft-altman-tls-channel-bindings is ultimately published as, either by
looking at the IANA registration for tls-unique or by looking in the I-D
DB for draft-altman-tls-channel-bindings.

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 n6SG7o47068370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 09: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 n6SG7odS068369; Tue, 28 Jul 2009 09:07:50 -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 n6SG7drx068352 for <[e-mail]>; Tue, 28 Jul 2009 09:07:50 -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 n6SG7dE4005816 for <[e-mail]>; Tue, 28 Jul 2009 16:07: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 n6SG7cOG013179 for <[e-mail]>; Tue, 28 Jul 2009 10:07: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 n6SFv9Mb007465; Tue, 28 Jul 2009 10:57:09 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6SFv8df007464; Tue, 28 Jul 2009 10:57:08 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 28 Jul 2009 10:57:08 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 28, 2009 at 11:13:45AM +0200, Simon Josefsson wrote:
> 
> Regarding
> 
>    [tls-unique]
>               Zhu, L., "Registration of TLS unique channel binding
>               (generic)", IANA http://www.iana.org/assignments/
>               channel-binding-types/tls-unique, July 2008.
> 
> I think we should replace that with a reference to
> 
> http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
> 
> and move that document along.  There is text in the registration that
> have direct implementation consequences and security implications, so I
> believe it has to be in a persistent and normative document.  Thoughts?
> 
> (Yes, this applies to GS2 as well.)

This means that GS2 and SCRAM will block on the RFC-Editor queue on
draft-altman-tls-channel-bindings.  That's not a big deal to me, but it
might be to someone else.

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 n6SED30g056797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 07:13:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SED3d6056796; Tue, 28 Jul 2009 07:13: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 n6SECxFB056787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 07:13:01 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6SECros008530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 16:12:55 +0200
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::EaHuqbmdRDKAldg0:E4By
X-Hashcash: 1:22:090728:[e-mail]::jZlvoPecIy1oHyWn:FSCM
X-Hashcash: 1:22:090728:[e-mail]::wJqMMl1xWhojk5nk:N2hN
Date: Tue, 28 Jul 2009 16:12:53 +0200
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Tue, 28 Jul 2009 09:50:24 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Tuesday, July 28, 2009 11:05:26 AM +0200 Simon Josefsson
> <[e-mail]> wrote:
>
>>
>> The IANA section says:
>>
>>    IANA is requested to prevent future registrations of SASL mechanisms
>>    starting with SCRAM- without consulting the SASL mailing list
>>    <[e-mail]> first.
>>
>> I'm not sure how the IANA would parse this request.  Who on this list
>> has authority to say yes or no to IANA?  For clarity, I think we should
>> use one of the terms defined by RFC 2434.  Is this IETF Consensus?  Or
>> Expert Review?  Or Standards Action?
>
> I'm pretty sure it's Expert Review with a mailing list as the expert.

I see.  I didn't know an open mailing list could be a Designated Expert.

> But given the agreement we seemed to have during yesterday's meeting
> that this family should have slow growth accommodating only successor
> hashes, I think Standards Action would be more appropriate.

Works fine with 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 n6SDodlh054506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 06:50:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SDodqr054505; Tue, 28 Jul 2009 06:50:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SDoRmH054489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 06:50:38 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6SDoON5018306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 09:50:25 -0400 (EDT)
Date: Tue, 28 Jul 2009 09:50:24 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Tom Yu <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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.217.197
Sender: [e-mail]
Precedence: 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, July 28, 2009 11:05:26 AM +0200 Simon Josefsson 
<[e-mail]> wrote:

>
> The IANA section says:
>
>    IANA is requested to prevent future registrations of SASL mechanisms
>    starting with SCRAM- without consulting the SASL mailing list
>    <[e-mail]> first.
>
> I'm not sure how the IANA would parse this request.  Who on this list
> has authority to say yes or no to IANA?  For clarity, I think we should
> use one of the terms defined by RFC 2434.  Is this IETF Consensus?  Or
> Expert Review?  Or Standards Action?

I'm pretty sure it's Expert Review with a mailing list as the expert.  But 
given the agreement we seemed to have during yesterday's meeting that this 
family should have slow growth accommodating only successor hashes, I think 
Standards Action would be more appropriate.

-- 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 n6SCV1WU047647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 05:31:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SCV1PL047645; Tue, 28 Jul 2009 05:31:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SCUmm5047621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 05:31:00 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6SCUd0u005440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 14:30:41 +0200
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]> <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::SqBvuJTfPFHbG2o1:25oV
X-Hashcash: 1:22:090728:[e-mail]::W29d6WAB+uZHK8Bn:5WCZ
X-Hashcash: 1:22:090728:[e-mail]::F5p3Lek7QjwpcQd3:6AEO
Date: Tue, 28 Jul 2009 14:30:39 +0200
In-Reply-To: <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F> (Chris Newman's message of "Tue, 28 Jul 2009 14:11:45 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> I consider TLS channel bindings very important, so much so I'm willing
> to invest significant effort attempting an implementation.  But there
> are three directions typical deployments could go here: 1. most people
> use "PLAIN+TLS", 2. SCRAM+TLS-no-channel-bindings gets deployed,
> 3. SCRAM+TLS-with-channel-bindings gets deployed.  If the attempt at 3
> is non-interoperable, then 1 will be the result as people will
> associate "SCRAM" with "doesn't work".  I strongly prefer option 2 to
> 1 and will act accordingly.  All this talk of channel binding
> negotiation is leading in the direction of non-interoperability and is
> risking the possibility of success with option 3.  I am stating up
> front that I'll fight for option 2 if option 3 looks like it will
> fail.  It's exactly because I care about actually getting security
> deployed that I'm willing to lose the channel binding feature if
> necessary to get an incremental improvement.

FWIW, I largely share your concern.  I may be more hopeful about getting
3 to work in practice though, technically it seems easy to implement.

> Now that you've goaded me to explain my concern.  I'll make a concrete
> suggestion to improve the SCRAM channel bindings section.  I suggest
> we replace this text:
>
>   Clients SHOULD choose the tls-unique channel binding type.
>   Conversely, clients MAY choose a different channel binding type based
>   on user input, configuration, or a future, as-yet undefined channel
>   binding type negotiation protocol.  Servers MUST choose the channel
>   binding type indicated by the client, if they support it.
>
> with:
>
>   Clients MUST use the tls-unique channel binding type if a TLS channel is
>   active when SCRAM is used.  Clients MAY use a different channel
> binding type if
>   an as-yet undefined channel binding type negotiation has confirmed
> the server
>   supports the channel-binding type the client selects.
>
> This way, SCRAM+TLS-channel-bindings will interoperate.  With the
> current vague text, it's possible for a compliant client's SCRAM
> implementation to fail to interoperate when communicating with a
> compliant server's SCRAM + TLS-channel-bindings implementation.

I'm not sure this change is good -- first, the MUST is clearly violated
when the MAY-path is exercised, so it is not internally consistent.
This was one of the motivations for SHOULD, IIRC, although I agree that
it wasn't completely clear before either.  Also you dropped the last
sentence which is necessary to get interoperability.  How about:

   Clients MUST use the tls-unique channel binding type if a TLS channel
   is active when SCRAM is used, or MAY use a different channel binding
   type if an as-yet undefined channel binding type negotiation has
   confirmed the server supports the channel-binding type the client
   selects.  Servers MUST choose the channel binding type indicated by
   the client, if they support 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 n6SCCFda045827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 05:12:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SCCFhj045826; Tue, 28 Jul 2009 05:12: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-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SCC2qA045800 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 28 Jul 2009 05:12:12 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6SCBnVV010307 for <[e-mail]>; Tue, 28 Jul 2009 05:12:02 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <[e-mail]> for [e-mail]; Tue, 28 Jul 2009 05:11:49 -0700 (PDT)
Received: from dhcp-14ef.meeting.ietf.org ([unknown] [129.150.24.9]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <[e-mail]>; Tue, 28 Jul 2009 05:11:49 -0700 (PDT)
Date: Tue, 28 Jul 2009 14:11:45 +0200
From: Chris Newman <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
In-reply-to: <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Message-id: <FDDB676380FC038C5B0BF598@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On July 27, 2009 10:48:46 -0400 Jeffrey Hutzelman <[e-mail]> wrote:
>> I am unsure how difficult it will be to add channel binding
>> support to NSS. In the event I succeed with channel bindings, but
>> subsequently experience interoperability problems with channel bindings,
>> I will remove all channel binding support from my implementation.
>
> What this tells me is that you don't consider this an important feature.
> That's unfortunate, because I consider security to be a very important
> feature, and if implementors won't commit to implementing a security
> feature, we have no chance of getting operators and users to actually use
> it.

I consider TLS channel bindings very important, so much so I'm willing to 
invest significant effort attempting an implementation.  But there are 
three directions typical deployments could go here: 1. most people use 
"PLAIN+TLS", 2. SCRAM+TLS-no-channel-bindings gets deployed, 3. 
SCRAM+TLS-with-channel-bindings gets deployed.  If the attempt at 3 is 
non-interoperable, then 1 will be the result as people will associate 
"SCRAM" with "doesn't work".  I strongly prefer option 2 to 1 and will act 
accordingly.  All this talk of channel binding negotiation is leading in 
the direction of non-interoperability and is risking the possibility of 
success with option 3.  I am stating up front that I'll fight for option 2 
if option 3 looks like it will fail.  It's exactly because I care about 
actually getting security deployed that I'm willing to lose the channel 
binding feature if necessary to get an incremental improvement.

Now that you've goaded me to explain my concern.  I'll make a concrete 
suggestion to improve the SCRAM channel bindings section.  I suggest we 
replace this text:

   Clients SHOULD choose the tls-unique channel binding type.
   Conversely, clients MAY choose a different channel binding type based
   on user input, configuration, or a future, as-yet undefined channel
   binding type negotiation protocol.  Servers MUST choose the channel
   binding type indicated by the client, if they support it.

with:

   Clients MUST use the tls-unique channel binding type if a TLS channel is
   active when SCRAM is used.  Clients MAY use a different channel binding 
type if
   an as-yet undefined channel binding type negotiation has confirmed the 
server
   supports the channel-binding type the client selects.

This way, SCRAM+TLS-channel-bindings will interoperate.  With the current 
vague text, it's possible for a compliant client's SCRAM implementation to 
fail to interoperate when communicating with a compliant server's SCRAM + 
TLS-channel-bindings implementation.

		- Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SB9faP040808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 04:09:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SB9f0d040807; Tue, 28 Jul 2009 04:09:41 -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 n6SB9dsZ040801 for <[e-mail]>; Tue, 28 Jul 2009 04:09:40 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 28 Jul 2009 12:09:38 +0100
Message-ID: <[e-mail]>
Date: Tue, 28 Jul 2009 13:09:35 +0200
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: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>Regarding
>>>
>>>  [tls-unique]
>>>             Zhu, L., "Registration of TLS unique channel binding
>>>             (generic)", IANA http://www.iana.org/assignments/
>>>             channel-binding-types/tls-unique, July 2008.
>>>
>>>I think we should replace that with a reference to
>>>
>>>http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
>>>      
>>>
>>This would mean a new normative reference and would delay publication
>>of both documents.
>>While I think it would be nice to use this reference, I am against
>>blocking SCRAM and GS2 on this.
>>    
>>
>OK, I'm fine with that -- it will mean a downref (right?), and I assumed
>those causes other sorts of problems that could be avoided.
>  
>
I am not entirely sure if it is. But I don't think it will be 
problematic with IESG, even if it.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SAiKdG038825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 03:44:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SAiKZ4038822; Tue, 28 Jul 2009 03:44: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 n6SAiGln038804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 03:44:18 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6SAiD07002467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 12:44:15 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::L3Kp+DkWzznGCBmJ:0hh6
X-Hashcash: 1:22:090728:[e-mail]::z8kACh6K61eP9xSc:1nfw
X-Hashcash: 1:22:090728:[e-mail]::JabRM2J8+X5pomA+:Jh0+
Date: Tue, 28 Jul 2009 12:44:13 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Tue, 28 Jul 2009 12:09:33 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>Regarding
>>
>>   [tls-unique]
>>              Zhu, L., "Registration of TLS unique channel binding
>>              (generic)", IANA http://www.iana.org/assignments/
>>              channel-binding-types/tls-unique, July 2008.
>>
>>I think we should replace that with a reference to
>>
>>http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
>>  
>>
> This would mean a new normative reference and would delay publication
> of both documents.
> While I think it would be nice to use this reference, I am against
> blocking SCRAM and GS2 on this.

OK, I'm fine with that -- it will mean a downref (right?), and I assumed
those causes other sorts of problems that could be avoided.

/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 n6SARdQ7037569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 03:27:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SARd0E037568; Tue, 28 Jul 2009 03:27: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 n6SARcPq037562 for <[e-mail]>; Tue, 28 Jul 2009 03:27:39 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 28 Jul 2009 11:27:37 +0100
Message-ID: <[e-mail]>
Date: Tue, 28 Jul 2009 12:27:35 +0200
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: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Chris Newman <[e-mail]> writes:
>  
>
>>Section 7:
>>    
>>
>>>    generic-message = attr-val *("," attr-val)
>>>                      ;; Generic syntax of any server challenge
>>>                      ;; or client response
>>>      
>>>
>>I observe that gs2-header does not conform to "generic-message" if it
>>begins with "y" or "n".  This inconsistency could be resolved by
>>removing "generic-message" from the document.
>>    
>>
>The "generic-message" rule is never mentioned elsewhere (noticed by
>running Bill Fenner's ABNF parser), so I would also prefer to remove the
>rule.
>  
>
Removed in my copy.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SAM4r6037235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 03:22:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SAM4Q8037234; Tue, 28 Jul 2009 03:22:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SAM39x037226 for <[e-mail]>; Tue, 28 Jul 2009 03:22:04 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 28 Jul 2009 11:22:02 +0100
Message-ID: <[e-mail]>
Date: Tue, 28 Jul 2009 12:21:59 +0200
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: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:
 [...]

>However there are several documents added as references but not
>mentioned in the document itself:
>  
>
 [...]

>  == Unused Reference: 'RFC4086' is defined on line 1065, but no explicit
>     reference was found in the text
>
>The first three should probably be just removed (?).  But the last one
>seems useful to reference normatively.  How about adding the following
>to Security Considerations?
>
>  See [RFC4086] for more information about generating randomness.
>  
>
Done.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SAG3IZ036886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 03:16:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SAG3rL036885; Tue, 28 Jul 2009 03:16:03 -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 n6SAG2kn036878 for <[e-mail]>; Tue, 28 Jul 2009 03:16:02 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 28 Jul 2009 11:16:01 +0100
Message-ID: <[e-mail]>
Date: Tue, 28 Jul 2009 12:15:59 +0200
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: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[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>

Simon Josefsson wrote:

>Simon Josefsson <[e-mail]> writes:
>  
>
 [...]

>>However there are several documents added as references but not
>>mentioned in the document itself:
>>
>>  == Unused Reference: 'I-D.ietf-sasl-rfc2831bis' is defined on line 1050,
>>     but no explicit reference was found in the text
>>
>>  == Unused Reference: 'RFC2195' is defined on line 1055, but no explicit
>>     reference was found in the text
>>
>>  == Unused Reference: 'RFC2202' is defined on line 1059, but no explicit
>>     reference was found in the text
>>    
>>
>This comment still holds.  -02 also contain a dangling reference to
>PKIX:
>
>  == Unused Reference: 'RFC5280' is defined on line 1042, but no explicit
>     reference was found in the text
>  
>
All removed in my copy.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SA9nb5036122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 03:09:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SA9nN5036121; Tue, 28 Jul 2009 03:09: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 n6SA9bZx036108 for <[e-mail]>; Tue, 28 Jul 2009 03:09:48 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 28 Jul 2009 11:09:36 +0100
Message-ID: <[e-mail]>
Date: Tue, 28 Jul 2009 12:09:33 +0200
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: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
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:

>Regarding
>
>   [tls-unique]
>              Zhu, L., "Registration of TLS unique channel binding
>              (generic)", IANA http://www.iana.org/assignments/
>              channel-binding-types/tls-unique, July 2008.
>
>I think we should replace that with a reference to
>
>http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05
>  
>
This would mean a new normative reference and would delay publication of 
both documents.
While I think it would be nice to use this reference, I am against 
blocking SCRAM and GS2 on this.

>and move that document along.  There is text in the registration that
>have direct implementation consequences and security implications, so I
>believe it has to be in a persistent and normative document.  Thoughts?
>
>(Yes, this applies to GS2 as well.)
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6S9GNxC031669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 02:16:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6S9GNAe031668; Tue, 28 Jul 2009 02:16:23 -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 n6S9GKeZ031659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 02:16:22 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6S9GHEo031731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 11:16:19 +0200
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::bRIIk8/UHjG07GPk:192V
X-Hashcash: 1:22:090728:[e-mail]::YWE7tKA5ukW/TKUo:8w/R
Date: Tue, 28 Jul 2009 11:16:17 +0200
In-Reply-To: <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 27 Jul 2009 15:17:20 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> Section 7:
>>     generic-message = attr-val *("," attr-val)
>>                       ;; Generic syntax of any server challenge
>>                       ;; or client response
>
> I observe that gs2-header does not conform to "generic-message" if it
> begins with "y" or "n".  This inconsistency could be resolved by
> removing "generic-message" from the document.

The "generic-message" rule is never mentioned elsewhere (noticed by
running Bill Fenner's ABNF parser), so I would also prefer to remove the
rule.

/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 n6S9DqpI031493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 02:13:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6S9Dquk031492; Tue, 28 Jul 2009 02:13:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-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 n6S9DnKP031485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 02:13:51 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6S9DjDr031688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 11:13:47 +0200
From: Simon Josefsson <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::J66uzUsSC6X+Uh2E:Ez5t
X-Hashcash: 1:22:090728:[e-mail]::6A5lP/wG4/30fk8g:IGrh
Date: Tue, 28 Jul 2009 11:13:45 +0200
In-Reply-To: <[e-mail]> (Tom Yu's message of "Mon, 13 Jul 2009 22:17:08 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Regarding

   [tls-unique]
              Zhu, L., "Registration of TLS unique channel binding
              (generic)", IANA http://www.iana.org/assignments/
              channel-binding-types/tls-unique, July 2008.

I think we should replace that with a reference to

http://tools.ietf.org/html/draft-altman-tls-channel-bindings-05

and move that document along.  There is text in the registration that
have direct implementation consequences and security implications, so I
believe it has to be in a persistent and normative document.  Thoughts?

(Yes, this applies to GS2 as well.)

/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 n6S95cYb030788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 02:05:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6S95cQS030787; Tue, 28 Jul 2009 02:05: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 n6S95X7s030773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 02:05:36 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6S95QNL031403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 11:05:31 +0200
From: Simon Josefsson <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::Df3A0IaS80LwspqZ:WaQL
X-Hashcash: 1:22:090728:[e-mail]::2OR5mgA9J+KyHXdE:02ntB
Date: Tue, 28 Jul 2009 11:05:26 +0200
In-Reply-To: <[e-mail]> (Tom Yu's message of "Mon, 13 Jul 2009 22:17:08 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IANA section says:

   IANA is requested to prevent future registrations of SASL mechanisms
   starting with SCRAM- without consulting the SASL mailing list
   <[e-mail]> first.

I'm not sure how the IANA would parse this request.  Who on this list
has authority to say yes or no to IANA?  For clarity, I think we should
use one of the terms defined by RFC 2434.  Is this IETF Consensus?  Or
Expert Review?  Or Standards Action?

My preference is to explicitly state that the process to register
further SCRAM-* mechanisms is IETF Consensus, defined like this:

      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG. Typically, the IESG will seek
           input on prospective assignments from appropriate persons
           (e.g., a relevant Working Group if one exists).

This appears to match the intention based on my reading.

If there are strong preferences for anything else, I don't feel strongly
about it as long as it uses some term defined in RFC 2434.

/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 n6S88KPl027346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 01:08:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6S88Kbv027345; Tue, 28 Jul 2009 01:08: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 n6S88HbL027337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 01:08:19 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6S88C9w029886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 10:08:14 +0200
From: Simon Josefsson <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::dY8CkpjsyCquIRRr:115N
X-Hashcash: 1:22:090728:[e-mail]::JGBKJ+qBxgdjNDsq:nqBM
Date: Tue, 28 Jul 2009 10:08:12 +0200
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Tue, 28 Jul 2009 10:03:29 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson <[e-mail]> writes:

> I'll get to reviewing the technical part of the document, promise! :)
>
> Running idnits on the document, it says
>
>   == The document seems to lack a disclaimer for pre-RFC5378 work, but was
>      first submitted before 10 November 2008.  Should you add the disclaimer?
>      (See the Legal Provisions document at
>      http://trustee.ietf.org/license-info for more information.). 
>
> The document has a long history, is the current legal boilerplate ok?

This was fixed in -02, sorry I ran an older document through idnits.

> However there are several documents added as references but not
> mentioned in the document itself:
>
>   == Unused Reference: 'I-D.ietf-sasl-rfc2831bis' is defined on line 1050,
>      but no explicit reference was found in the text
>
>   == Unused Reference: 'RFC2195' is defined on line 1055, but no explicit
>      reference was found in the text
>
>   == Unused Reference: 'RFC2202' is defined on line 1059, but no explicit
>      reference was found in the text

This comment still holds.  -02 also contain a dangling reference to
PKIX:

  == Unused Reference: 'RFC5280' is defined on line 1042, but no explicit
     reference was found in the text

>   == Unused Reference: 'RFC4086' is defined on line 1065, but no explicit
>      reference was found in the text
>
> The first three should probably be just removed (?).  But the last one
> seems useful to reference normatively.  How about adding the following
> to Security Considerations?
>
>   See [RFC4086] for more information about generating randomness.

This comment also still holds.

/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 n6S83mAR027127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 01:03:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6S83m2I027126; Tue, 28 Jul 2009 01:03:48 -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 n6S83YXw027109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 28 Jul 2009 01:03:46 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (dhcp-11c1.meeting.ietf.org [130.129.17.193]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6S83UkX029731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2009 10:03:32 +0200
From: Simon Josefsson <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090728:[e-mail]::rQaXyCsUW9g+UWZR:7lOs
X-Hashcash: 1:22:090728:[e-mail]::7FjzQgOGW1wObdaK:pgpz
Date: Tue, 28 Jul 2009 10:03:29 +0200
In-Reply-To: <[e-mail]> (Tom Yu's message of "Mon, 13 Jul 2009 22:17:08 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'll get to reviewing the technical part of the document, promise! :)

Running idnits on the document, it says

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

The document has a long history, is the current legal boilerplate ok?

Idnits also complains about these references, but these complaints seems
bogus:

  == Missing Reference: 'I-D.ietf-sasl-gs2' is mentioned on line 1014, but
     not defined

  == Missing Reference: 'RFC2743' is mentioned on line 1019, but not defined

  == Missing Reference: 'RFC4121' is mentioned on line 1025, but not defined

  == Missing Reference: 'RFC3962' is mentioned on line 1022, but not defined

  == Missing Reference: 'RFC4401' is mentioned on line 1030, but not defined

  == Missing Reference: 'RFC4402' is mentioned on line 1034, but not defined

  == Missing Reference: 'RFCXXXX' is mentioned on line 807, but not defined

However there are several documents added as references but not
mentioned in the document itself:

  == Unused Reference: 'I-D.ietf-sasl-rfc2831bis' is defined on line 1050,
     but no explicit reference was found in the text

  == Unused Reference: 'RFC2195' is defined on line 1055, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2202' is defined on line 1059, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4086' is defined on line 1065, but no explicit
     reference was found in the text

The first three should probably be just removed (?).  But the last one
seems useful to reference normatively.  How about adding the following
to Security Considerations?

  See [RFC4086] for more information about generating randomness.

/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 n6RKw0MA087484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 13:58:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6RKw0ZP087483; Mon, 27 Jul 2009 13:58: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 n6RKvkvg087458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 27 Jul 2009 13:57:59 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6RKvR4Q012271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jul 2009 22:57:36 +0200
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090727:[e-mail]::Spom6NqbBl9DD+0c:44Cu
X-Hashcash: 1:22:090727:[e-mail]::2+d2NNhxM7on0pRn:78QW
X-Hashcash: 1:22:090727:[e-mail]::ehjwkaUh1RF8NA3J:RIoY
Date: Mon, 27 Jul 2009 22:57:26 +0200
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Mon, 27 Jul 2009 10:48:46 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_48_96,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Monday, July 27, 2009 03:17:20 PM +0200 Chris Newman
> <[e-mail]> wrote:
>
>> Section 10:
>>>   SASL Mechanisms registry.  IANA is requested to prevent future
>>>   registrations of SASL mechanisms starting with SCRAM- without
>>>   consulting the SASL mailing list <[e-mail]> first.
>>
>> This at least needs to designate a successor review process if
>> [e-mail] goes away.
>
> I don't think it does.  There's plenty of precedent for setting up a
> mailing list as the reviewer; if the list goes away, the IESG can
> designate a new reviewer.

How about changing the e-mail address to [e-mail] so the e-mail
name is at least under the IETF's control?  The address can be a forward
to this list, if we for some reason don't want to move the list to
[e-mail] as well.

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 n6REn3va057983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 07:49:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6REn3o7057982; Mon, 27 Jul 2009 07:49:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6REmpBq057946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 27 Jul 2009 07:49:02 -0700 (MST) (envelope-from [e-mail])
Received: from [10.0.0.4] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6REmk3K011584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 10:48:48 -0400 (EDT)
Date: Mon, 27 Jul 2009 10:48:46 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Chris Newman <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
Message-ID: <[e-mail]>
In-Reply-To: <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F>
References: <[e-mail]> <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F>
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.217.196
Sender: [e-mail]
Precedence: 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, July 27, 2009 03:17:20 PM +0200 Chris Newman 
<[e-mail]> wrote:

> Section 10:
>>   SASL Mechanisms registry.  IANA is requested to prevent future
>>   registrations of SASL mechanisms starting with SCRAM- without
>>   consulting the SASL mailing list <[e-mail]> first.
>
> This at least needs to designate a successor review process if
> [e-mail] goes away.

I don't think it does.  There's plenty of precedent for setting up a 
mailing list as the reviewer; if the list goes away, the IESG can designate 
a new reviewer.



>  I'd also prefer the document enumerate
> principles for when to allow registration.  Personally, I consider
> undesirable to have the family be large.  I'd prefer it contain only
> SCRAM-SHA-1, and in the future SCRAM-SHA-3 (with the -PLUS variants).

I agree the growth rate should be small, and mostly related to the 
introduction of successor hashes.


> I intend to implement it excluding section 8 and SASLprep.  I will
> attempt to implement channel bindings, but it has gotten fairly complex
> particularly with all this stuff about different types of channel
> bindings.

If you ignore the discussions and look at the result, it's not that 
complex.  Assuming CB is being used, the client tells the server what type 
to use.  For now the only type is TLS.  If you're a server and see 
something else, you can reject it out of hand.  If you're a client, have a 
TLS channel, and succesfully negotiate the use of channel bindings 
according to the spec, you can assume the server will support TLS.

> I am unsure how difficult it will be to add channel binding
> support to NSS. In the event I succeed with channel bindings, but
> subsequently experience interoperability problems with channel bindings,
> I will remove all channel binding support from my implementation.

What this tells me is that you don't consider this an important feature. 
That's unfortunate, because I consider security to be a very important 
feature, and if implementors won't commit to implementing a security 
feature, we have no chance of getting operators and users to actually use 
it.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RDhaGa050557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 06:43:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6RDha3b050556; Mon, 27 Jul 2009 06:43:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-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 n6RDhXTs050545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 27 Jul 2009 06:43:35 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (95.209.66.91.bredband.tre.se [95.209.66.91]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6RDhMK2032310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jul 2009 15:43:27 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090727:[e-mail]::rmh5CNYhdHHcyhsb:JG4n
X-Hashcash: 1:22:090727:[e-mail]::Bkq72hHrR6MDitae:bwZN
Date: Mon, 27 Jul 2009 15:43:20 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Sat, 18 Jul 2009 19:39:08 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_48_96, RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> In general I think the document is in a good shape. I have some minor,
> mostly editorial changes. I don't believe another WGLC would be needed
> after they are addressed.

Thanks for your comments!

> I've already sent a couple of comments to the mailing earlier (See
> <http://www.imc.org/ietf-sasl/mail-archive/msg04104.html> and
> <http://www.imc.org/ietf-sasl/mail-archive/msg04105.html>). Here are
> my remaining comments:

I'll look at these next.

> 1). SCRAM contains the following text about authorization identity,
> which I think is missing from GS2:
>
>    Upon the receipt of this value the server verifies its
>    correctness according to the used SASL protocol profile.
>    Failed verification results in failed authentication exchange.
>
> I think this should also be mentioned in section 7.

I added it to section 4.  Section 7 already contains this:

	      <t>Authorization of client principal (i.e., src_name in
		GSS_Accept_sec_context) to requested authzid
		failed.</t>

> 2). In Section 3:
>
>   If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
>   implementation need some other mechanism to map mechanism OIDs to
>   SASL name internally.  In this case, the implementation can only
>   support the mechanisms for which it knows the SASL name.  If the
>   GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation
>   cannot map the OID to a SASL mechanism name using some other means,
>   it cannot use the particular GSS-API mechanism since it does not know
>   its SASL mechanism name.
>
> Is the last sentence still correct? I think this is out of sync with
> section 10, which now says:
>
>      The output variable sasl_mech_name will hold the IANA registered
>      mechanism name for the GSS-API mechanism, or if none is
>      registered, a mechanism named computed from the OID as
>      described in section 3.1 of this document.

I think the last sentence is still needed -- consider if the function
returns an error code (e.g., out of memory).

> 3). In section 5:
>
>   If the client supports channel binding and the server does not appear
>   to (i.e., the client did not see a -PLUS name) then the client MUST
>
> I know this is probably too subtle, but does "a -PLUS name" means "any
> SASL mechanism name ending with -PLUS, even if it is not the same base
> SASL mechanism we are talking about", or "the base SASL mechanism
> name"? I.e. should "a" be "the"?

I agree -- I changed "a" into "the".

>   either fail authentication or it MUST chose the non-PLUS mechanism
>   name and use a "y" gs2-cb-flag.
>
> [...]
>
>   If the client supports channel binding and the server appears to
>   support it (i.e., the client see a -PLUS name) then the client MUST

I changed "a" into "the" here too.

> Note that SCRAM also says:
>
> , or if the client wishes to use channel
>            binding but the client does not negotiate
>            mechanisms
>
>
>   use a "p" gs2-cb-flag to indicate the channel binding type it is
>   using.

Should this be added?  I'm not sure.

> 4). In Section 6: Multiple missing commas in examples.
>
> According to the ABNF:
>
>    gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
>                        ;; The GS2 header is gs2-header.
>
>>   Example #2: a one and one half round-trip GSS-API context token
>>   exchange, no channel binding.
>>
>>         C: Request authentication exchange
>>         S: Empty Challenge
>>         C: n,<initial context token with standard
>>                            header removed>
>>  
>>
> Should be "C: n,,<initial context token with standard"

Fixed.

>
>>         S: Send reply context token as is
>>         C: Send reply context token as is
>>         S: Outcome of authentication exchange
>>
>>   Example #3: a two round-trip GSS-API context token exchange, no
>>   channel binding, no standard token header.
>>
>>         C: Request authentication exchange
>>         S: Empty Challenge
>>         C: F,n,<initial context token without
>>                             standard header>
>>  
>>
> C: F,n,,...

Fixed.

>>         S: Send reply context token as is
>>         C: Send reply context token as is
>>         S: Send reply context token as is
>>         C: Empty message
>>         S: Outcome of authentication exchange
>>
>>   Example #5: using channel binding.
>>
>>         C: Request authentication exchange
>>         S: Empty Challenge
>>         C: p=tls-unique,<initial context token with standard
>>  
>>
> C: p=tls-unique,,

Fixed.

>>                                header removed>
>>         S: Send reply context token as is
>>         ...
>>
>>   Example #6: using non-standard channel binding (requires out-of-band
>>   negotiation).
>>
>>         C: Request authentication exchange
>>         S: Empty Challenge
>>         C: p=tls-server-end-point,<initial context token with standard
>>  
>>
> C: p=tls-server-end-point,,

Fixed.

>>                                header removed>
>>         S: Send reply context token as is
>>         ...
>>  
>>
> 5). Section 9 says:
>
>   There's no requirement that any particular GSS-API name-types be
>   used.  However, typically SASL servers will have host-based acceptor
>   principal names (see [RFC2743] section 4.1) and clients will
>   typically have username initiator principal names (see [RFC2743]
>   section 4.2).
>
> This might be trivial, but I am missing the following text from RFC 4752:
>   ... targ_name equal to output_name from GSS_Import_Name called with
> input_name_type
>   of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
>   "service@hostname" where "service" is the service name specified in
>   the protocol's profile, and "hostname" is the fully qualified host
>   name of the server.
>
> So possibly reword this paragraph to read:
>
>   There's no requirement that any particular GSS-API name-types be
>   used.  However, typically SASL servers will have host-based acceptor
>   principal names (see [RFC2743] section 4.1) and clients will
>   typically have username initiator principal names (see [RFC2743]
>   section 4.2). When a host-based acceptor principal name is used
>   ("service@hostname"), "service" is the service name specified in
>   the protocol's profile, and "hostname" is the fully qualified host
>   name of the server.
>
> ?

Nico?

> 6).
>
>> 10.1.  gss_inquire_saslname_for_mech
>>
>>    The C binding for the GSS_Inquire_SASLname_for_mech call is as
>>    follows.
>>
>>       OM_uint32 gss_inquire_saslname_for_mech(
>>         OM_uint32     *minor_status,
>>         const gss_OID  desired_mech,
>>         gss_buffer_t   sasl_mech_name,
>>         gss_buffer_t   mech_name,
>>         gss_buffer_t   mech_description,
>
> Do the 3 output parameters need to be freed?

Not sure if this needs to be mentioned, I can't find much discussion in
RFC 2743 on this.  Nico?

/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 n6RDHmP0048245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 06:17:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6RDHmeU048244; Mon, 27 Jul 2009 06:17: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-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RDHbj6048228 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 27 Jul 2009 06:17:47 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6RDHOQs002260 for <[e-mail]>; Mon, 27 Jul 2009 06:17:37 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <[e-mail]> for [e-mail]; Mon, 27 Jul 2009 06:17:24 -0700 (PDT)
Received: from dhcp-16f4.meeting.ietf.org (dhcp-16f4.meeting.ietf.org [130.129.22.244]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 27 Jul 2009 06:17:24 -0700 (PDT)
Date: Mon, 27 Jul 2009 15:17:20 +0200
From: Chris Newman <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <B23F14EC827605D7976D1E02@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It's been a while since I read this, so I re-read it from scratch.  Mostly 
editorial nits:

Section 3:
   implementation may chose to use the same iteration count for all
   account.)  The server sends the salt and the iteration count to the
   ^^^^^^^
   accounts

Section 7:
>     generic-message = attr-val *("," attr-val)
>                       ;; Generic syntax of any server challenge
>                       ;; or client response

I observe that gs2-header does not conform to "generic-message" if it 
begins with "y" or "n".  This inconsistency could be resolved by removing 
"generic-message" from the document.

Section 10:
>   SASL Mechanisms registry.  IANA is requested to prevent future
>   registrations of SASL mechanisms starting with SCRAM- without
>   consulting the SASL mailing list <[e-mail]> first.

This at least needs to designate a successor review process if 
[e-mail] goes away.  I'd also prefer the document enumerate 
principles for when to allow registration.  Personally, I consider 
undesirable to have the family be large.  I'd prefer it contain only 
SCRAM-SHA-1, and in the future SCRAM-SHA-3 (with the -PLUS variants). 
Perhaps we could briefly discuss this at the meeting.

I support advancement of this version of the document on the standards 
track.

I intend to implement it excluding section 8 and SASLprep.  I will attempt 
to implement channel bindings, but it has gotten fairly complex 
particularly with all this stuff about different types of channel bindings. 
I am unsure how difficult it will be to add channel binding support to NSS. 
In the event I succeed with channel bindings, but subsequently experience 
interoperability problems with channel bindings, I will remove all channel 
binding support from my implementation.

		- Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RCk6OG044988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 05: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 n6RCk6rB044987; Mon, 27 Jul 2009 05:46:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RCjskU044971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Jul 2009 05:46:05 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n6RCjqND018887; Mon, 27 Jul 2009 08:45:52 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n6RCjp1M022308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jul 2009 08:45:51 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n6RCjpuW026075; Mon, 27 Jul 2009 08:45:51 -0400 (EDT)
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: GS2 presentation
References: <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Mon, 27 Jul 2009 08:45:51 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Mon, 27 Jul 2009 13:03:25 +0200")
Message-ID: <[e-mail]>
Lines: 9
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson <[e-mail]> writes:

> All,
>
> I've prepared one slide on GS2 for the meeting.
>
> /Simon

Thanks.  Now uploaded to the meeting materials site.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RB3v0d034756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 04:03:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6RB3vlA034754; Mon, 27 Jul 2009 04:03:57 -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 n6RB3h0i034731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 27 Jul 2009 04:03:55 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (95.209.39.205.bredband.tre.se [95.209.39.205]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6RB3RST027276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Mon, 27 Jul 2009 13:03:33 +0200
X-Hashcash: 1:22:090727:[e-mail]::rRRqb3a0HCYw/KR6:RqwY
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: GS2 presentation
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 27 Jul 2009 13:03:25 +0200
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_48_96, RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=-=-=

All,

I've prepared one slide on GS2 for the meeting.

/Simon

--=-=-=
Content-Type: application/pdf
Content-Disposition: attachment; filename=gs2.pdf
Content-Transfer-Encoding: base64

JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nJVVS4vcMAy+z6/wuTCpJVuxDcGQzOPQ20Kgh9JbH9BDoXvp368kPzI7
2w07LKxjW58lfZ+ksQOYv4c/xpqjHZwJyQ3RUCL+fv5uPn8wv/VS/p5/Hpb14NIQjBfb9Zv5eAUD
3qw/Jgt5/XW4rIenV/Y0+IcAhBKCHRmmCDReEF8YYjEfcbIuf10//Q/r48DWzg1jgTp2Nuy7C07y
wZF9Vm8OizefKUyWspvsmI8w2WCjTbKd7ZI5jJOenu1FzhbdRL2Tr2sGFK/8DZYNAOqFPjgDysLm
4DoaPFDZEE0wQhCY08UGiIoubwiGrb0s6S0yIjIZLo4DdTJQiNkhA2xgNly0jUA0GJUNmDljYO9O
MpBgT5UTanGh8tTvzzbe7C77UXr/aIwu3kd41RDmfKQaDlqJucSpkQmHbBIzTMjK+Im5leCWDC/s
KrwUW6rnLcmCrMdzKwyFheqAtjsEdAXHFMTiW6xoQi81VHhDCRQkLJL7kbc47hY5psgsPFTkmGBI
d0XOVbZIeRGGPMriMNaUtMSvOb0qYqHAJkyaBP/nrIiTLfQKdFdqJLjpzveJjZ5aspvcSpLVIETn
rSqpqhUquaUiUsYm10nE6jK246JKgaZawXT7mmpcyoRJ2xVnG17vFQdSan26iXPVClKKUelfWKHK
eJkisSbdyb+ZUILFbeQQIKpKJ06d81/q0Lmw8PpCe04sxaA0xNzRbdlTFyi1Qf9udYFcw9w1M2qn
csLj1tFdENVbDu56VzBVUbeNpmrSX4Ha+zhXPRsUoQIadVUCsLVYym2Jb2zdKuPRtm4OWlnU5wac
7w76QPDbQEAZCNskhVzHAs96Sfn0Fu2VQ0T+IX/JIZ6lQ2Sg4EW+rjfPB8m+dk6hw6ZOLYfTnT2Z
f4hsvvsKZW5kc3RyZWFtCmVuZG9iagoKMyAwIG9iago2NzUKZW5kb2JqCgo1IDAgb2JqCjw8L0xl
bmd0aCA2IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAzMjU3Nj4+CnN0cmVhbQp4nOy9
eXwURfowXlXdPd3Tc/UcmSuTTE8mMwlJSEIOQjCa4QiI3KcEiSQkAwnkIgeHggQPQERBd0VRV/BY
FS9CCBhAl6y63i7sqqi4Cq547rKyu8iuYmbep2omCai77/d9f78/fp/fx3Sq6qnqOp/nqeeorkBb
S3sY6VEH4lCouqGqOV3OVhFCbyCELdXL29Q7/9R2HOCTCGlyFzUvbrjywQwzQpKCkNC5uH7VIiQs
6EPI0IvQiK9qw1U1I0etNyE07knoY3gtFKyNXC9C/hTkU2sb2lZ2WE3PITRegnxvfVN1VfOYqy6H
/CuQX9hQtbK5Vr6TR+jyLMirjVUN4Wkvv3kz5CchlPmH5qbWtm0oI4pQG52j2twSbv7VqvvdkA8h
JMM8EIaH/ugB1NA84XhBI0paWac3GE2K2WK1JdgdTpc70ZOU7FV9Kf7UQDAtfUhGZtbQ7Bz0/7sf
4SByQXALjyIXH0ROhKKfQ/iCppG66Bf0PU3JV1C5Jx4Qegw9hevQU+gweh6fgVa70QHUjV5BDjQW
3YdWo1+iDUiD5kHJzWgGPAKU/xK7ot0oBz0AvPQAehPqXomuQweRHTujX6K16CbuLWh1EzKgFDQK
TUNN6FY8KdqO5qMT/A2oCE1CjagZd0TnRm+L3hF9GP0aHeBeifYhHXKjanjejP5NeC/6JzQUWtyJ
tqMT+A7tPhSCUTqg5q9QC7qHq+BxdHH0O5iBD62AOfBoMnoT95JM6D2MPsdOvJobA708FO2Mvgi1
PKgC1aJ70EFciMcTnzA/Ojn6JrLDGCuh1+2oC+2Hpwc9h45jvXAm+nD0DHKhLDQB1tONfo97uUjf
ukgpRTRgaQgqhjdN6DfoZXQU+/FvSZOgF/KEkHBN9G1kQ8PQbJjto9DyM/wvch08a7mX+HHR0cgI
eLmdYhv9Dn2M3TgHT8VzyBDSRO7nWpAEIw6DpwbVAb7vht4/wpl4P9GTI9xD/BP8eU1S5GTUCBQJ
onvRr9BvsQFWquJWfD0+hj8hY8gCci/5M/dLfhf/R7EKVn01akC3oifQv7AFj8DT8VW4Fq/GG/Dt
eDt+Ex/FX5BRZBZZSr7marll3HP8aHhm8q38DcJ64RbNF5G5kRcjf4j8K5oXXY+mAz+sg9nfie6H
lR1AR9D78JxAf8YC1mEjPCr24dn4Wniuw7fiB/FjeBfuhlGO4j/jL/E/8Df4PEHwaEgi8ZEUePyk
hawgvyT3kSPwHCV/Jd9yDi6Fy+QKuRKunGuCWW3gtsKzj/uYd/NH+CjgOU/YJuwQHhOeEJ4Xzmj0
4vUSkt74/qG+jL6PIiiyMbIt0hXpjn6MEoCGbsCCF5XA7KvgWQL03gYctxu9hfWAOzfOwJfhSYCZ
BXgJXoZXAiZvxPfgX7O5P42fBSy9i7+GORuIh805mxSS0WQqPFeTMFlGtpI7SDc5Rr7jRE7HmbgE
LoMbz1VwYa6NW8Vt4zq5N7gPuT9z57jv4YnyMu/lU/ggn8mP5xfw7fz9/Of858J84XXhU42sadCs
1/Ro/i4OFy8Tp4nTxQpxi7hffFuqBO58Ae1Dz1y45/FJbh1Xxu1Dt5F83kV+T34P/LwA1XCTCXAq
eQxvJGtwN0kVVmouIZfgKegMHwRcv0R2kHPkEm4ynohnoiVkWKw3jY1/HJIS/gV0mn8W1vZ76Hml
Ro+vI19r9KgLI1IMY/6Oy+UzudfRce4EFvkH0Ae8jB34NHmUmwZc8Bx/mTAX+bj70NPcMrwG7SNl
ILHPS5uBj6fgx0EuzMJ5+N9cFHFkCnBREfcJugEtJe+h07CPN6K7cA2/GN2G8vFq9Dl6BHbFEKFR
k6FJwK+SOn4TseJuRPhdsLpinIo5wYZuxBXcPZqvyfuoHR3hZfQR9yTM/gh5mpvMnxFm4FrYAWvQ
erQsug6tEubyf8SLEYfnoAB/EqTbai6P90G6FqTKfJBp+2F3HwQ5MIqbDCVO4JxJwBezQULcA8/d
ICd44KA62ONXghT7PerWzCI9aLFgxCB1EOJfj8xA86KPoO3RxagxegcaCvJgQ3Q19PgY+hRtQY/h
myLXomaUDDvnIzxJGEeOCOOiQ8km8j6ZSbZdTF/AdgA70VfwPI3GocuEQ2gT/y6aiUqjm6PvAHen
g4TdjhaiK9ApWOXfYITLuV6UH5lC9kTHcc2w3hNoevTRqBfLqDZaj6aiZ9GvRQFViZmhUaNCpZdd
WnLJyOIRRYUF+XnDcnOyh2ZlZgxJTwsGUv0pPtWbnORJdLucDnuCzWoxKyajQa+TtZKoEXiOYJRV
5h9XqXYGKzv5oP/yy4fSvL8KCqouKKjsVKFo3MV1OtVKVk29uGYIai76Qc1QrGZooCZW1BJUMjRL
LfOrnW+O9as9eN70uQDfOtZfrnaeZvBkBm9lsAFgnw8aqGXO2rFqJ65UyzrHLa/dVFY5Frrbo5PH
+MeE5aFZaI+sA1AHUKfD37wHOy7DDCCOspF7CJIMMKlOt39sWafLP5bOoJMLlFXVdE6bPrdsbKLP
Vz40qxOPqfYv7ET+0Z2mTFYFjWHDdGrGdIpsGLWOrgbdou7J6t20uUdBCysz9TX+mqr5czu5qnI6
hjkTxh3b6bjmlHMwC51bxszdcOHbRG5TmbNOpdlNmzaonTunz73wrY/G5eXQB7QlgXGVm8bB0JsB
iRNnqjAaual8bie+CYZU6UroqmLrC/vLaEnlErVT6x/tr920pBJI497UiWas8nW53aED0ZPIXaZu
mjXX7+ssTfSXV4317LGhTTNW7XWFVNfFb4Zm7VHMMcTuMZrigN5wIRAeeMcgVp1CE2cMYBbTGfkn
AEN0qtUqzGSuH9Y0gkbhEWhT9QioBj/lGFp11gBF6jq1Yyo3KSNpOW3fKQQUv7rpGwQc4D/914tL
quIlmoDyDaIg5ZMBVoP3/XBnZmZnRgZlEXEM0BTmeBnLFw7NWt5D/P5mRYUE0IemAW6rykfmAPp9
PkrgW3pCaCFkOjumz43lVbQwsQuFcjLLO0klfdPb/yZhNn3T0f9moHmlHzi5mxm/CZ1ScODXpNit
ZbUjO7H9v7wOx95PnOmfOH3eXLVsU2UctxNnXZSLvR8x8C4OdVrHzOUSSRwiiRx7C0w5f6AyzczV
d/IB+NUwpq7pESXgSlaC1XGdSuXlsbhc9vn+h416omdoK5YMNotPs3Nk5sX5Sy7KXzQ9/SYOJgxK
cOKseZs2yRe9A1aLDTghngDHo1lzfeqYTjQbdmYAfnuivSNoKE/sDAHKxtAKwH+xonj2ooqJcbgc
fih3Ds0aB4Ju06ZxfnXcpspNVT3RjoV+VfFvOkCeJ89vai6r7GecnujBWxI7x20uB1zV4pFDEcHM
+BQQWLMiGt1N8CmN2EO2h6xI4E9xSBb5Uxi5JI1winDPglLXgomXjZyZyrmSvpIpytmSyX0lqBRg
5XuIhuX6zD5zACIMKu17lev9PiSg80jle6l31RD9XDggvIUC6L1QWaItMYFUpuGrJSu2cKmpyGdx
kABKJhhrHMlGzpes0WIcTAukqhynEjWtknCkpSMNpyUFVRnLrmD1Vc5MmELF5NOTlYpzFSWTlb4S
s6U4B5WeLj0NaQnLwi+GYCkeljtmVWgs70/0uD0uD6fRB5VAQtAblAKgBAJOQ5IP2U1WH1S2WVUR
cilCwIc9OocP28wQJWt9PpTKQYQy4QdnZiolSklm/0/GOlyBKnBhwKzh/SmppLDAkpqfx9sdYjbx
p2g0oibBZuHz84YXmblJpGFL5OjO9yI7uvfiaR/swPiO4G7fwv1NNz2/wjdiAya3X3fmMlL6JO47
2dJ6AF/93jHc2r2455e5zR2Tp984deOOFyP/7qgqwmaK1fnRz/m/AFZzUSR0XzVXzbdybTwfSCvk
ij1juAnipKQy79jUcWkzuXJxftKV6TdbjemGYCpJ5dICw00F/rGBspx56hz/7EC9bolhqXGRLexc
pbvGcI1pjdKe2hpYz23S3WzYZLpVuSn1hsAdhm2mbQnJgVSjQSf4wA1OBNUNmluDA6kpUKYRkhOH
bnFj92nwgxQw3qeByGvGW7EG9+DOUGBocrKdE5KHahOD7iu0QTQED3Hn+YIWHLTMUmE1rmEDZD11
Wjk9RTkH9D17mtFU6as4BeGs2eIoNjsoZYsxgMNyUcUyXLHMWpRMAL/DCwuCacHUtGCwsGD48Pw8
O5AgGAQSJNgcdt5hB8NDowEKBec/Y1jwypqmx2dOm39JpH563eLr/vHLh75dLxw0PbWr84HiEfj9
uR3XrD//q5cj/9yO31Uab71ydOvYssV+R1Vm0UPhpt/W1L2xznjLbeuumpqfvzT9kn3L24+0tn0J
aygBm00UesEe+zw0/BLhEs0h4bDmkPiy9KpHnKAv188yLtXXGK+xXGO92fKs5VP3p4ln3PrDumes
JFHxKElKsqL5DbiKIuhDCVJt9EzInSwrkkbzmsdt83jcksfNYSK5PZwhWekhD++dasbmHuzcZ0i2
CSi5hxwKmTDRy62Ot4BDQj5/AT5E1iEVKXhESG/eVwouXRNZS3hykKQiL96y5xa6pSvOnlbOZZYo
FN2weUpPA74prjGNNhizM41rlBfpZgKMj4AfTCPg+YqWQIIvWDR8eBFDPqBaTGOYp5gW4ZcXvy8i
jsBD93z92PZrr78PH7D++w9vnbv80ecfnJ/81FOjSqp7r3vx00VLf3HfJuuR9796au7jzz68sWoY
YFIL0mmccBDJ6JvQ5TkCzkDpXEDO0efqK/U3Szdrt+p79Wf0OlU/TQ+L0UlE1mpVSbBJkoAwVolg
I0TQYiJ8qcpI0oYlHCYSyM6QLr14moQ7pK0S5DEOGUgovXgBwVvAjSGElphVYZpAcoVKYavQK5wR
BKGHbNyrq3zMmekC7lx2qmJZJg1OBdgU8OV2nXaWlmwQsjMBSRuynTTBEzt1Myd22kCDdCGT3BP9
e5fWgmki2UhP9G8j2E85VEuHasOh2gGEqGQflgv8DOLEh/Ox3TG8CBIyqu+VP+I12d6UoXjzS33P
CwfPv9vRvHIlP+S7ceD+Tox+wSfzl4H9noQ+CtV4kSeBzOYqhArtbF2YWyo0acM6SQEGUEia5X3h
O9s5tzjMMtI1zDPKMtk9yjPdMt81w1NlaXBXeVZqViacI+ecCrJjk8HhmGavtDfbObvHtFXZqRBF
4RM9soh6yOMhLb7T6uF1jpCBYlWbllHQacAGtxdyewPBApqGkpL9Bble7LXnK6liKDWjwCuWilNF
TnQlFxTF9nrm5L5TU5RlmZnnlmVOppu97xQT4RUlfctKKMcx+c0E7LIW7KD7F5kVlJ+HzDbRZ7fD
tsc+2PXAetzVB7P+duDLyNfY9qd3sBF//4XcdVP15r7jZLp+xJybV+/CcxwPdWMv5sBXT498FPlW
UXcfrMV3rh9T+wiVpzeBH/gSYNKMbghdkmPFCo/9fAE/hp/JL+LbeI3WLGklrcFq1hoQJ2GdRyNi
DZK16VslLKWoVmwlKeYARnTpCfnDC85Qy0lFR9FJ0IlTLONfZFttWWZJ3yml4mzLKVRaWnraXFwM
v2ylSHl1g3HNi1SqteCKfHN+At1LIMPovtIkmG968LK60quuvmz06EuutiXzwQeWXT7y0bTxpZUt
fW/T+ZdGv+D2wPxz8fuha/kUW8pI7RXasalzUsIpq7W3aW9MfcT6RNbznEHrcDsduROzjjmERDKb
ECUPy8750nztfHm+br5+vmGJtES7RF6iW6JfYugOdqeZqFRNHTI8dZ5crqsJ1qS3+dtSO1J/Id+n
vyP9rqw7cx+Wd+kfSns4fW/wd0F7Uk/0o5AluXielBbQy7xbDSbwuuwkN+Uaj9dV6prqWuDa7Tri
0phcXleT64SL97q2uIjrEJkNXIygmqLgECYKPooJwgommHKVzV5A01Cy0VyAcfb8pPokkuRJEHlP
ts4LeifVFbI6C1w95KouMTUDaj7jKT6agTPcebRVEDi0Mq83j5TmdeSRPAVjnIrUVFPKCYRLwZUl
oID6mXLZZJCHp1umKEAsxpdnM0+3MEW0DFgzM7NiWQtVRxAPmBmOmJURShua7BdsWUGzYlGsCqdJ
MaiJSJsuJmJhKETJNsj6jP5ElOI36KUhciJOT9PKmkw+EXmVpESM4sYFizAzLzLXrVuHMqmia1lW
YS1iPF9YkBZMywZTg0reH2g6eJJJTNUFS7tMN1+7emVh4BcvbZ86akTG7TPXPDfP3KlvrVu9xG7P
Sbzx8F1z6l5ac+R9fKlnaUt47KV+ZyBvwrop41elezMvv3axc8b8GUV+T5JVTs0ftXr+vB1XPgkE
QhuB3UpAOlPbcU2oYqp2q3antlPbqz2hPaMVkdarbdZ2aHfEi05qo1rZq8UIizzhtBruOow0goaX
NWJAQPwOfiffyffyJ3lNL3+GJ4hX+aOQ4/kp0vhpsT3TUkKtzVLQTGyn0EClQssya2F+AmfON2/s
7u7m/3LkyPkEPnj+OJ3jWJCLabAbDMiFfhuqsIiySz9ec7k0R1MuLdbUSVKBMtIy0l7oLFMmWiba
y5zzhfnaGUqFpcI+w9kgNGhrlAZLg73GuQInaDWC4SpuljBLvkpfz4WFsFyvlx0eXjR7dDpbqkgZ
zJoaKMgVMRIVUQURN+xEIk6k5S4qBAE2pqIQVPGiUpjcMDflNVhZ5mkQfmDDAsAYDFYF4n8ZuDAh
7UxhpnahsFDL44pyq1IEdEYxsiKrLcYElORjH775dx9g+7V/ueVE5PSBrg3ru/betKGLWHHabcsj
H/e9+ZfrcTI2vPH6G3/43euvgZTYACb/Z4AXO3ojZBU4jZU8pvQon3CfW89w56waHvyi0DCdoWCV
gu9WjjpPOqNOXpVsRpvd4hFA4NkNssGoN6bqQiDiojoMv7opTrpSd8Hwgk7nGSdpdu50djp7nbyT
I/kJ9rhItPxIJDri4rDkbAnbahBOA9+DTmWCEcdNd7vGrJUlWZQ5jRI0a4yJ2CRb6FbBMeN7Gd0d
TFyynWBPMPvNBbHtYN7wYPuHlQ9MU+TujKWXtz7KB+/aXdY8OW9NXytZ39gw6o43+p6FKY3CPWQJ
aQB+zgq5mkkzRybjyYRgPyJuoZkap3zzrVQ2nKpQPkM5k4FMCPajtdCXMIoMwT379lH5ewLY7jxY
fzJqDalcyGAuWMqvJVvIdol/ksda4HngfgHrCX5NjmEE7LNchKn169YLIYOpQKDFRlosYFUICURw
6Q7iEnwTio0OijKGM+Z9lVILLa4eM31+MxhchWCL5ZPz3aPemnXXn3Pa+GsvW+19evxrC+iOcIN1
qjCbyoDOhoZb5upr9ffod+lf1QuTuEmGX/KcBWxLpNdwoiDrOBHp9QbDaxxv4zieMyCiN/Aid4gc
QhK4jztDMuJ5qIJek/kesugZQZBDSd4CuQcXhQxiKMVfIHb4CsWtJkLXZDDYChBRiAq+3D5jD97M
DM+/VsByMjPPgun5mcJWBI7luZJ+hbghO5MHY8pkMsEaYUscQIboR12WYjA53g7p8ou5lKHFHJ+U
xHyxckAC3TY2fUhXrO+YVqwPBYv1KR5IhxYzR60c3NNCTBnFb+bMmGzru5H86hcvvdQdKcQLfs3t
//6KX0ceAGvyzr6llOQIicsBW068OTR2CAqah1iCzmI03FxsGe6cgMabJ1jGO+eiK81zLVc6lbul
u030o6FANCLYoLJOr9cajCaT3ma1WOinQ2dCT7Rkr4CcKk31FjNNQ/MSJK2KBEJUjGwYI6cgSckJ
TltCgtOi12qTEywAWsx6k0lVzDZFMVu0esmZIJjMih4RIUEvcE7FZNJqJQnYlTgtFrMZSW6Hw62M
0uLpsNX0ECdACCEBT9+vqqD3XK4efMuex2K6zu2a3Od29vW5XX3OKWXhsZ/B7qPKJxbTh/oBcZnL
AtBlcnbmhjXM1v1RAnjeYFRefBGikhf7oQsjsHlNYPOaqWlskUFwnIsZwgEozBg0hFHMgjZCyV59
SAiNYLZxCzWMrTHD2GqBxJqP/TiYBpYYvj9y7csnUt0jZOz46o9T/Z6hn70QaTwUeT1NdNgirwoH
vy+9686/pHIf9bkjf/3nLd3c09+N4ys2q+Hx5x+iu3cb7I4MoLeA8kN6THguWUCSymNg7kdDRpFw
KtuoFZpL5jPJTY8+PquI+UvDcoGrzL6Ebc+TPwoHv/vnU1BxUfRzYTl450moJ1RZTZYkERXlGapR
M2pL6kA3Jm1F9whPcL82HOC6DS8bjqJTSf9MMhstSeakJC5Dk27O8Kje8YY5tisT5rhqhaVJ11pu
sdzDbTfe43kMP0weM79jtCIbcis2xc3DFvuoK72YmUdp6cWKCWE+0Zqs5xKTea0SNF2BgpTwbq8j
qIKt6kqunt9/gnKRn22mZgxI1QqQqRWY2tsXnmjEbQywLSxU/fDdz18aeeHT05F3792Nxzz/J5x1
yeH853+x65P5DZ+tf+jPhAz7+vxvceMfP8Wz95x8fejOOx6MfH37ociXm54FWTQObNUTgG0z4OdY
6AmZ8IaAocAw1iAU2go9V5JZ8gzbTM9iUiOEtdW2Sk+v923hHeuHrk+tn9q+dvzF9WnSSW/Ua/d6
M90l9hL3RHezd6tXzCaphmz7SFJomEjKDONsEzxXynMMiw2faj63f4fPGhWcwBl1gJ5Ej040IznB
w+mc+RgFzKaAohw1Y8UcMleaO8y8uc2Selg8Ip4QoyJ/gdsyrd9CBBd5WQl4gH0lpyjqSmgwF8dc
5Aqmw32F1AILAvKoXnIAg+AL1DY3Ivzi2nfal7x9Q+W2nL196pPty3/92LUrH1h//+bzD+3A3Kbp
o4jxu3HE8sZrv33p+BsvAs5GR6ZzX4HmTkYZ6EyoUqcDQ1MXsE3Sldk02iRXUpYuaMvyF+uG267Q
jbPNEefqanXfyd8kGLP9WWmX+S9Lm5S2NWtnljjcN3xIadY43Thf2ZBZvllD6sRqX/WQyqyOrONp
X/j+5v86zeywaxJ6yJ7udI9VxNRwV1SUiyqBeTtQL6hv6gOuCY0SPB6TXJbi0cv2hPxAvhxwOo86
sOIIOSodHQ7e0WbCAZTiTT1sOmI6YYqaeK+p1DTVxJlcmVltPorMzCkMmWfpEQ/gs+/UOdACp0+x
EwialjCHGFUsc1DDlh6iDU8DtJIYVh2F+eaYoXuhRbRoty5vTNuajU4jXt75wZnGP9z67DWPhD/Y
+Zuvtj+yZvVjT12z8rG57umBvJp5RZ234JIP78Z4890d3y/595GVT3AZf+g9/MYLL70A+J4d/Zw3
gz5XgEf3dWtUl+IB46iLqLrfRE8iOwQLBFP0ZGghr9lANuo2ml41ClpR5yRl1kkJV7jGJM6yzk8A
9zpxqbhUV22tT1jqqkxcRVZoluuuMW3Q3C1uU151HifHNMd0H5jc7mResCUbDI5WLT25yQWLWato
iXar19yK+g0DFSQ5QVuTX76l335kZlO/8UhxxY5o2BmNVWG8Z7ckKASwlBa0KhRNZgXQJGpmL31r
5/KuttFL3nrg7VW3H9i1evWuXdetvqKCvIV5fOmTC/ZGoscjkcgLT939DP5V5K6vz+BavORvdeup
tJwT/Yy3A24y0VuhdMFgN5QZ1hv4MvOV5uWJ3Ax7vbLEVmNvN6yyrTdsst2c+GuDLKhcD6BKR2/U
8CIG9wfTA6wQdHYI00sQBlzYrdcn8M6D5GHkIrWh1IRkj8AnDzFYWheoTSpRO8TWIMNMEKOgEiTB
rUOdPXhEl+stfBCPoHojpBtEUVYPvmNPP5bOxvF0tiKGqj7quuWwg8VBBw5QFjtpGPCyKJ6KBjkr
frpFj7dEGiPgvDnd3juXrt394Jr8STaLrrVn/ZK6zbZu31dPr3xt6aKa67dGvjj22yi+wbl9Q+f1
qx+w3U9Wrqm+/sYb1X0vL+6qWXBfdvJzt/VGvvkMkWgfQkI5yEQRGXFyqDpHyVUWS7XaSmUjt1V5
VXhJ06ucUXSSUI7nkGlKra5T+af+n4Z/GrW8njfwRk4nawWeB/RKGlHUAyxp9CK1t0W9DQoIx6m8
3gY1tMmCICVrOE0PaQ5pkaT/MgTGAzmIdQhjXciiV1FY5GZM44/wJ3huK9WBGId00/S94gk9t1WP
9TSvmEA+krVih0jEX5iOvQuYhr3sggC/TnCg3S7l9GnkLC1xny49BbISfn9wStZvT4BZYATzQIil
QIiY8k8G5d/NmzhJPBg9A+T9d+zQDNxgPwa9z/k4q4+jyh/cjD+QuR8+0XfvA+/jv28fl+LJBzU8
Dj8bGUvm4W0HVtx6C7DZDaBzTrLbTM8dQG56apXgKCCq1V5gok7PEIutINOKUyWrXY+tdp0GyWbQ
DyjfHnA6mLPjwL0O7JjiZgc81Nlxn3GTZvdOd6c76ubd+oB24OiH7l1VexR8X147xdXvxsJujfs5
JX1MbZSWxExd5ue4ecVoMBmoBamRBAm8HV6fiAySORFRXycjYx3wJthXccWSFiwEnQIOv52dfQPM
la5+5+qHpiq6bp25cfr02y7pvq/78oapha3kjr69tw4bP33mlo2kGNxjjFKj/yAZwnbkQB0HkBzt
3esPFrDZjwKgwwW+ut4gYw7ZFW2mSdbYAREmJQWlYIMloMdRUSrTllWKzUD8rSKPwOPdKXaKveJR
USMeJEvAaB6+Z1FszWdPAeXBVjp1toQpyj5Qk5Zic36+8iqVV5mZAUdMT5r9IM2LmHVuo2siintS
ycL6rBtv3LtvnzUzPfmBHcpl4QdJ9WYs1kdu3dz3i8lZbhSX0y526p6BfhMqGOmeZA/5r7Jf6V/E
1dsb3Iv917jXJG9235J8j32X+1n3V/bP1HOq9VL7/fan7NzIITUaknYQBLkfpJPTp2rU9OSpxgVG
YjR6UpJtAn5rGuCrh9R288keg/cgLkY6PCJkdjJJ5ASbXXES59YsDJKoG+0LtJoHRDUYE8S8NfPl
Hwohds5ZET/oPM3kDj1Opx4lEzyXgXpL08TUHAJ5YzEz8R3EBbEzHkrw5qfsq6tmrpk2HA8/1LD/
eyy+tOX0tdf8/cEnj5PXf922smvX6jUP4JnKNY2T1r7XrHfOWYql905g5Z7IJ5F/RD6P7H36MFdw
7/4X79u8ezfF4f1g/faB7DHA7rgyVBg2L7WRicpE21XKVTZep082GY3I4UwGMYEkS1Byq24Mv26n
IW4Vuwat4inKsopz9CyX0jr2NS7mooKFnMeOpojPZwY49r3G77ufDLljcv0d5X+LvBrZiK999v6K
ScNujNwsHDRawvsbDkX6+p7k8Oa1829IMNBdDOqniJ09bT6ABODcohHMbd5bUBhLc4fF0pRAzJ0O
wC43CV5hh3BC4KdCdEbgvEKz0CFEBR7Eo0y42AkF7YnpWXd+YcEOhHvRGcDM4HEFP3AalZkZO49i
CreFOZfUAbihm0odaHNF9AveA5ZaOirCSaHbtAZthsvgzhhiyMgoNgxPKEocmTEho8JQkbHEUJdR
mbvJsH7IPfZ73bsMCY+4Hk/f7zqU/qLrSPofEz5Ml8basdfhdWZmZRQU88VZE/jLs+ZI5ZmLpLrM
5foN4Lt/a/g201xUYMS8kpNa4Mjz2ZwLhjQNIUM8OcZS4xbjDmPUKOww7jZ+beSApTkHNefszjtt
Ho+IytLkPNjaQ6qUKhTwpfaQq0JKWogqVzWYG9wdFILDiilGvPQQq7i3mOwsxsWOgDMlJ/Ww5oiG
eDWlGqIZNoJihbI3k26nz5b0ffop3eyn+hUtvF0WOyvt17VxIznArDf6va6IPfRgkynay0j8MAfY
3eEPchrRSGKcD5W4kpoDS3Y/O7718sKlxxfj/LKNa1cldTobj9688fFpitaR8qzHsfDFpvl5DXW1
DwaTbpg97ombpqybYjMa3KkBuXHopeXLnMtumRiquiJ75ZnzN106An+Y7lHSJ+dcXnnV1EtX0PMY
hLgvQFfI+OpnCgWMUszFMj3XNpiLtXaLp0CiEbhdX+2FFMdTqPFeSJvsK0DpEEHui5AWuBDZIYLc
8dC+9OwCpEJk0g9B6dqgXIwK5cvReHkOqPRyaa52EV5E6qQ67Uq0Aq8gq6SV2hXyBryBrOduFjdK
m7S/Qndrb5efRA/Kz6FnxD3yq+h38nH0jvxX9Il8Hp2Vs2QkyE5kl9NRUC6Sp6IQ2AQhi71ACOkM
BbIoSQGtbNNqZcQREoidOQiyjOTYAYJGlLUcwkIOqPgUKRQKaTvA/uzBiftCsF2IAFBIq5IQTtF9
9Ue6F0DH91X0Vbidp09VxD7WFA+cH5iLqbYfPBkAmmdmAtEzL/hBA/48OPL46Uj9b04FgNn/eiDS
yAf7blzcNGs52UjPczHSgHX0DFDEQvaA6WHDGfwQmVxhvsp8m5kzU/2t9foKFE9SGtVjZ0JPeVML
eI1ea9Ukal0WgUe8RqfVGSWLgqycTfRIibokYyoKiBlSprEAFYojpUuMY7nxmpA4WZqoG2Mab77C
cpVphmWpWCMttqzSXCO2SQc0B037Ld9ozmvTdeZ0lG5IM6ab0iw5thGoyLJCWi/dzd2lfxQ/Rh7T
PaLfh/ZrDhpf4Y9p3td+wX9h+txyVvOd1mPh2CGRKGhlWdLp9bJiNoP9MXGvgCxqT3RCaJFsMqov
mEVJFc0WS6Yg2gRBNMp6fcBgtBnAujObTJmyZIPm9OQoTkVEsGjhJZNZbzTIZpnnLAa9XpJEkZLV
YqLyW7adUwy40tBs6DBwhh78aEhWp8q4SV4rE7mHzA5pp5pxk3ktKC2a0ykCrmRykgPCP7oPn7Oe
W8TcX9fksxUVTnDY4JcyQIXzp0+N4hxhZvH/4NBINColNFCYhomd3plzuw2qXiXPgoLGEIzRo90o
16RawJfAI+I/5RM7C2bOPYCk6NE9ItWmUOAD+zGfHSdJ0ZN7RDVWaolblQdoR/tNKu1b6oke7RJz
aY9daAQ5GBtpoPOBdg7Wzhw9uVdWeZU6WeX9x5LG6Nv7LcUoC0JP9O091mJ2Hsk0A1pWgRmTMx63
OtiJFZfG4YmRQwd3lfL5uw7sKLx0/+5I96FdQ94Fpr/3lPk10th39+tvkkXnj5PV+74/Atx/GLbA
Oqb1frmP6mDCVNyIS2OqLr8glg7NjaXpQ2KpP6YC9yYlx1KnO6YScwxKgSpsFXYL4BMA72xBO1En
4nPAcZqGToDaEywqFG6F4R7kj5UzrQcL7eoA/6CinH6NGdjFMTVItd/h5+Pab0OkjveB9rOARXYk
9Gu9MlS5VJmo8KVqp0q86hC9PykvIS9pdFKzulWVRjpGJl7huCKxXLpKP98xP3GJtFRfpzQ4lib2
qm/ZPnR+6H4r+ZTtVPJJNara/XymkplQyI9UxvFXKPOUT3V/SYooOrORs3vY51i7x6hDRlfqURkr
ckiulDtkXm7D1nySbwkg1IvxVrwTd+IzmPfiUjwVc9jlHV/kxLFjnRZ6l+gs+7hHDZjT7DtE/EwH
3qJl1vhXWer9MZsszcxdcPSw4eGRd9RuPLqk/cS187Zkmx9ZvvKJR9ta90TqhOc2TZ++OXr3Q5Hz
t0wa2Xeee/jNF19/5/XX3gXaTgO/5DTgy43eDI3X6rHXM8Y6xjHTOtNRaa103Evu5e4xPKw87NZL
Bpe8hNRxS4R2Pd3EIGO0++V9er1dv17/CeGMKQtMTaa1Js7Ezmwm5DJ60lObrUDgk0BXLTKZdGDq
WTw60enhdR4TNqUaUxKpR6DL9IIcwRhP8CSkHhExPfUi4rDEgvh3a2q8tsSvxR2ALdI7ovx0y9n4
h1HQ8ebiHKXiFPz2X8vp/1wfPwDr/0JJscWV7En6+unjkX+1fHnzU3/y7natnbfx8YdvXHIbvsnx
zBGchOUnMVm3+4HEpfUvvHXs+ethflYQcR3CW+Cx7A0l27TY5Mpx5bpCrmbXvfr7DLsMktuQbuh0
9bp4F2XxdLe3IEkycHqTR8YJJNNm5Tnw6HbYsC1qDfGOAA8q8A4cM/yGxQ0/2eMt2ApjPeR0PYsP
Ih86h2XkzASbJpPejgGxBm7t6Qpq2pawezLF5pjrZlPMGq2okcAYUrSWRGTWmBIx9dnWrcOZYOe0
5FPvprCgaPCLfkIC9XS6duywum9YPml+4oi8GWOPHOHu2bxsacG4Ky2/ksdVLtz8/SKYjS8ynfsb
aD433rDX5MEmaoc87ClOt80x7Za5kCFkIiY1PbdAoRE4/ha7wWlJ06Xp0wzD9cMNhcbtZl26Jd16
ub3cUm4tT6iz1FnrElZplhtWma+xXZNwk2GTebNls/Vm293yY7pnlUPmg7av5M9t3xj6lG9tUU8y
qA+9AroIrAaXzWoNWGQbZEx6UDYBnWzT6WSrxaLX6zScx2VCHsVDcjyHPcTTQ0r3mawhS8jWQ2aF
dKWWkIUssBy2EEsPHr3fhFNQWaJMX1lMqi4UUvW5+ql6bpo+qid6qLE3B7gT+uhOVFeD4nG7lD56
tADGBj1ZcCpnT7noJ7HTbqdymkHISR1Mqn2o5SHRgwYBFAy9vIRAF9FPEiUSaBUjSHMncPEhpI9+
gXTRL/AFstwW/Wh/UbGcUlRsBANuX0KxOSWhOPaBaRkT55ngpqXFDNEi9h0ibr7QC0/+lLW2S7JK
LneYg4Iu0vD8h5kp3sxPuiP1o1JzV88piCzepaSnJi41JfHpfdvb161eTpaef2X36PKZKP5llv5l
lQ3tOYDs9KMZeC4BvpAr4w4aeHZ6lupwFTgks95s48AoNXnAONDJ+oCWHU9oca8Wa6fYKSc76PGE
/YydNNt32jvtUTtvJ7b/eDclYeCAgnrqkJyNnSnSU21z8eCXWKPGKAaMGn0iNkim+BdYejcBM/cn
JhbZx1d67zHBvKH7ut7lT0/sbl867dYS4WDfP+6oePi+vgXkgQ3XzrxtTd8h0BUPgFX3FP3KhlLw
pJDJojNiy3DPPO8iqcHLg0r+816LuwDSM3tT0grMNA8GnhJPTfEU3r+3NykYew/1lXhK34daAQgY
r/Bcoc7Uzfc0eFq0K42rTDfJG013GXaZekxfGD83KUa9XjWbbGCJmU2wgRKJz22XNeB3G/SCU6u1
O9yuZIcD+VKYB+x0gj0lJQeN92kq1NTm1I5ULjXFGfeE/ZfEv6zRb7RKxTnXKefpAeuIOcRQXFKc
wwyk2O06ARg0dhYyYBbTL5myFDIVm5SRZstIyn54WdzW+CjkdgFXuootEIwhT7GSYoPghRDjVFqb
Otvxg0qH3WH1c9kEPCs/87uZsvI9QDa9+MY1r701OX32pOjZ52c3XjnUN/Fj/MBN26bc9VAkVzg4
9ZVV9x1LCqROaY8sw8Nu3DxCJ/a1c/lFq8bXsjPguxHSmIB2Cm4PrUXEJNlIosQvB130ip7T6ifo
J5i4IXzAkGWcy13FLzesNG4wSDoiSOADG6eSidxYMSRNNow2yneT7dw2cZv0GPeoqLEQMFZzBQJm
L5H0BkOuIAEo6WeYZtBbQUSif5apA0PYqCBJSyotHSBQDpLHkAEP6xLAnMPDQrJeK6sh/Vod1h0k
c5AR6+AN6cG6kNaEkWpqVrDSQ+Y8owqVMfuWPLbXfEl57IYfkM4JNGJSBmD3QOZUBUgYEP3KBY8b
FMKP/JzB48vnQMScBxP0GCLRY/Erf3p4l86UqCH67z1GmZbGv26/vd9XbMzysS/cIIWMeUUM3DcU
SuNfsTPLW6jjXEFviPlidwR9sOewH5vvxqn4qly7qxAvwMKhyJzdkbnCwfP/uP3yafdy3383jn/9
fCF/8rxKaWcCWfN30CkKXvGMyYJNwEkaqlf2u4rnmbbx26TtxntMvUKvpld83aQ1hezFbs6qTTC4
lUI8UrcO36aTcixX8uViuW6u8S58t3y37hnSo39F95rxDeU49472D4YPlE9li0Wj4URJq8UajVbg
OU5ngs1mMGCTyaDoMNISg47TK7IGVJisvIRe0hIlgLQ2hLQcMbxkwIaAnrPp9Zys1XIcKFcDeDVI
nmrBlgmG6/QpsqlKo70uJINj+kxIM03TwQ61x4SMKncdSZkKC51gXv1i/Ior81VBeyifKmdPs0+3
gy4LJWFFnIYVcX1RbDJtkJgjEoshEZkKKYnpim6jM6lYR7GmSyrWpziKOQg03+UrVpg5kVCMU3zF
Wtii/Tu7nN1WAT+4AvzdfAclXxFA4BFgE74xsv3jh7I9WYG970Zux7d8eHxk5EuSjiPfjs8dnX8+
ou/7Pb6iPFJB6TeP24vT2NfqYCgBCRwW/kYQt04F85bgJZplj7I104NGHLssZeXoTamN2W/mQkvL
N99E/hbTOJogWJ5+9NIBpI2+FxqlM4DGOcWf0n7s+FQV3hHOqcQhqX6tM1EFAviTPZoEj05HLW0/
7Aj5aABvDewMkIDD4TYGtrLLyBX7nIGt9PITrgi5EMn3B/BRhKkFSujlp6ngVLhSAz145V7f+P4v
gGB3952CrQf7rY/dQgBbm9pYsNsm02u2ZseFd/mNeps1aNObE7HFkNCvhtglmP5Lk4BXegv5gotA
F2ilB/IeWbL8Lu91r93/+F7//Muaf9k9t2bSupF88M4pCxbOPbh7f18a+VX9gpF3Ptx3F+lauXLa
Pbf3vQ+6an30C95L5R37Zv0kFvSmVKFQKBOEUm+nl3i9KZ58z2gP/RKtGWmln6Un2Se5K6QKw1xT
hf1q9xKp3lBrarQ3unu97+uPO467/mz9q+Ovrk/Yt2yXKuSYcmy5QqkpJEwyTRMWCceTvuG/U/RK
gpHXEJRIHRw5ARwcZ+pRHVZ0IV2lrkPH69qwOR/lcwFCftK9SR7ff63xYu+GOjelg5+smXvj88f0
eDJJUJA/JY2zOQadGzz00e6WPQt3LwtF/vHcs0tJwezblz/56/blT4Jq/2bL1C2vtUa+jhz7Fd52
ePYtb75+9KU3gcM2gpz5N+BMh98IuUXNHM08LWcy/FM4p+FmcytkYtGoVl+BRBW8JXZy0w2pRWAF
vthRzo1QouF5gdcUacfzQkAzVJ4rr+Da5ePcJxrxEQ32a4JiQCrWjNCWGqYayvlyzVyxXLuGXyVs
176k+SN/THNK86X4L823UoJFlsHn5YlGI2q1EmS0khQQNTZR1HA8HxBkUDWyrIWMBIqe/SMAkk6H
ZL4Hm7qEFFAuppBfZZ6ReyuIJ10AkQBgfeASqd7wsW/8ojhbx5h3irKs/45FXOKUllDNL8SuNw3Y
qKIigWzhWByTMCFZm5VUrJWSkkqodO5KokL67S6VJXt88WtNTBuAWMlkSkQT7QX5A9Zib5edJh91
KUy0Q8Jyepbs0fVrE/pFiQ5l+ZDHks0Oo9lsJSyCVue6nLTxX/ckxqqD989YhZp7mMotLJo3duPH
v4wswYc/ijywVjj4/bO4M7K8r4Z4r4lcRa3M6OekGPw2Ds08gDiYgK2YXlcJqbbiuzhMuB3cbo5w
yxG20X93AUM9mfsCkS9wD961D1zVvdc46W3Ys7HL9rGL9hUDBlMCncWurZG5LuGv39ni93iEGYzj
bgoN48CMl7Qj0+RCzXB5vHwlt557lxOXy+9z78tcurCZ3yQ8zn8lCTKPC/ljPNFSI1sLjMepNIJ5
7tUXW2gp5UYpnvI0TWJp716LnZZ/FLrUBSMFApdKWpfrUspeMvCXAEylxpgKGE2NMZosI4HwmIg6
CUkyR0AP8j1kZMiUK+CdQqfQK5wUeOEKiZbpckWsih1ip8iJPWR9SKdTmZWpp1YmFZh0L5+lzjkw
VklJTGhCADOTIsrYz1+U0URJAc4CA8QJBkgiM0D46HvM84lrJ8oHZi3YAlKWq5inISWxGPbiR/vt
ANpjJoLOUiyBwcmHbMV04fsCAA7YnYyl6J9J4WUtlC9jH0awD8OvaN72PHkPi33byfVR1HfuDMiN
IeTdvqe/v5t89lWEp3+LRm9hfRm/F5SB1oWm8fw4/xz/In+r9katps7dLjRrW3U3CDfoNGl2LedM
y0i2J2m1VktyRsaQIciTRA10b3KyGUnOoGZWIKh3ZyUlx03zzAs/Up2L78i+frO8ROkroacY9D5A
7DpA/JvV4Pd+I/FjX17sj13AgoZ3RfRbHYW3keBjr7cuWnzTlis7frs58gt86boRV0wcd/39kQ9w
w9XBMfNGzrpzcwRcnfID4asfyU97tmPxnsph3AyzfdHkCU1Dzu8U9SOWjpuxahjlYfpF0yc8gpLR
V6Gkie5VSZuStlkftb6gP6b/IFHSWp3GDDenzRVydfS0kgOeVaxygsVqfc1oshmtNqPJ0EMeDlmN
cnJCyLiTfss0hRJwQoLH0kMOPWPi8Vv03kUPdob89KumeYHSpKxVtii80iG2/uDLpmp5FhciE74T
DOwRXcZ9P3XXwnvxXYvB2xYlF37qNEMAgXhqgxTzeRDTPeykFV9wtT32AcjqS/BxsTvPIj1om/1c
wvb667uf2nzl5vRdt5H3+56ZeuPtvVhqu/XsK324Q9l0y4sP3tM1tdRO/v5kZPn8yLk/vHx710n2
Z+8QyB/+Wvjqx58sMJV8IyVK7K/hH/wkLaP/L+OjfZHpIr2tB4Zn/N+CYe3EyyJT0JjBP6D/wT+T
kquhHyaKUYMwB83nW1EJpFpIJ5LH0U3Az6X4ZbQR8mMhbKD/3gGUjwL4BAS3eCtyQbpNeBktgnQc
hNEQZkOYI8yJ9kF6A7RJpWXQ7/3Q1w0AXwH9uqGNBt4dpv1CfhrAVkh9NA/vHtA8ju6GvAlvQPMA
3gDl6yG/kc4B+tpGA+0X1jAcfYwfJ1PJKe5m7kshWWgWvtesh2eX5ltxq7RR6tSWat+Xb9d5da/q
V+mjhrBRNM43Pm3aosw1v2sZavmdda71HdurCWPsPnvUcQI4Zrsr313grk+cmPh7T3sca7loBOxu
+kPAfspBo2Gf6+U+KCNQNo6bglD8fYTFHGsnsxzHWhmxFIc5dDW2x2EeybgtDgvIia+Lwxqovy0O
i+hF/HAcllCQ1MZhLdpEbovDMv8854zDOrRQPB6H9WiRVBKHDZpu6cE4bETzTXMG+GGtqSsOYyQo
w+IwQaIyPA5zKEe5NA7zUKc+DgtIryyLwxqovyYOi2ihcmMclpBV+SwOa1GZ8m0clkmV+bI4rEPD
rDsG/hWjfOvROGzg5tm4OGxE2Y4KmAnmKdb1jlsYLFCKOO5isIaVP8pgkZXvZbDE4BcYrKU0crwV
h4FGzj/EYaCR84M4DDRyfhmHgUau8XEYaOSaHoeBRq66OAw0cq2Iw0Aj9yVxGGjkrorDQCP3X+Iw
0Mj7VBwGGqmmOAw0UtvjMNAobQiDZbqutJsYrKNrSbudwXpW/gCDjQyO9anQtaQdYLAVYEvaywy2
sTrvMziB9fMpg+2s/BsGu2jbdMzgRFonPTa3JFon3ctgL4MzGZzK6hcxOIPBZQweSndG+kwKS2z+
cZiNlb6AwvpY+VIGs7Wkr0Cz0CrUjMJoEapC1ZCqaBeEWaiWwZNRE2qE0BavpYJ0a0ItANO4Csrr
WA0VSuqhfTZAY1l51f/DnnIGZqaimfCmHrUP1GmFsgmQxsYbhorhyUVD41AeKx0FLeohnQFtFsMc
2lirGdBfK4QWtBziGqjVAu+roCZ9sxjGqIdcy49mO/KCmuoP6o5Ec1iPrQMroDMYAbGK0qGnOphn
C7xphbAIehxyQV//qeVgjcmAh8Hc0wyjFF810LKBjb8UymjP//e4VqGUrqgOZtLGZkRxo0Ke1mmL
9zob6KCiaay9ioJsvMkQT4WxFzGcV0F92i4MvVIsr2AtaW/ZPzGnGH2bYFw6p2aou+o/1gozvqL1
VrBZLR4Yty7OtUMZXZrQwvisp7A3tYxzqmA2WQNzb2Fv6hiHzoS4nc06RocYN1EKjGEzaWNY7sdb
C8xFhVpVcR6McVIdw30N4yzKa41srAv5pTreVxWbG23ZwHqk866F8RtYjzHsq2zWVWy86jg1Ym/o
rFvj9Khia4y1WzVA/7o4lzfHKRhmuGllnBdbXT+FquLzb2ejqWyEC2fVT3mKG5pfwfquvYAbaN0m
1lds7P7yGLbb4hipjnNq64/qtUGfYYaVOkhjfVfHS9oZpilHDfJ0E9uxLQyj9aw9nSmlZ0O8Vf8I
1az98viodfGVxvYe7WEQC4vYHq6Plw7itS6O3ab4SupY/XaWG6RqK+PSeja7n+aJfpnaOrAW+q6B
9TfYB5UNS+OzrYrjv5pJOzW+S/txVsPGXsxKY+3pDquL07CW7bvmOI80QUx39PI4tmM9DEr5Kkar
GHeoDIfV8fXXMarVszrNbO/FuLGRtYyt5ELurhvgLLrzV8Yp08BmQ3lzeXxvxeRO/cA8GlhukHvb
fqCJWn+wvur4GAtZD+0M0zUX8WYYLYPyfsy2s3/Pr3+Fixhvq4wHVjLctjK+axuQJzGq07nH9ntb
XGrEdlNrnMsGpWfsbQOjSBW6hrWPzZr2W83eDnJabPQahq1mtktWDayif+xGJjPp+yqGiZb4GHQP
xbDYxtr3z7i/92bGQw1MbvbPLZvpvDZ4NxJ0aQ70S59sVutCCZvNpFMD1Khle6keoAaAGhmFwizX
ihYwHohRPHug5v+7I6xgHBOrG75glCkg6WeBvh8HYQxwHoWnQinVAOMgnsTKy6BkJsSUN8eDJiiD
ZzIrnYUM7G8YZSZL6uL744dWT395bJ/EMNocx/kgj/7PtNggZfolcj+dF7K3q6B++8CY1QOyLcbP
g/roQmkZkxyDcjS2f+viMrM1vqcXs17CAzKR7tby+Gh0dy+Py9KFA9ooNmbbf8FMv+xcMSCdwvEd
Fx7g6RYmP9ri+3lRnB9/Cl/9u5BiLHxBL4O7+Mfj1cQ1IOXAhUwyxma9ME6ZxnjPP0WhNLaqizEV
k8g/5oofj9wv26gUq2I2aBWMWh/HdmtchvynsSn2Z0PJoJxd9SNahONWxoU2V0x6V7EZNTPM1sUt
nf8JzdU4LzZeINv6x6WSpIZhuu4CLdJygY2cNVC75QK+HdTd/x1TdHYNrP9+vmq6qL8VjP5LGTUv
tEP75eNgzSaoG7NQ2xnGaf+1A+uJzetC7m6IS9QY/mO7qjnOH4OS92Ie+m8rGuSPCWztP6Zcv+1F
dU44bqHFVhOz96oZVRt/QIOWH+B7sOdWZq1Si6QmroeWM9toBbrQuvrfU7+/v5a4/VcX93V+yor7
MR1j2Bq0WKtZnz/ex/0Uq/oBrhf9H812EMs/HuFifX/xjMJxK7YNdE9/D9Q/GYVinkA62PAFqAh8
LRXiYZAbCh5iAYRcRE8JZqOJ8Zq57N+8LYAnBhehfAi01XBUCL4ADbT3/zNd93+vGfvf5fwAewP6
cNaq5vCiquqwukudVRtWJzc1NrVBkTqmqaW5qaWqra6pUW2ur85Wx1a1Vf1vKuXQztSZTfXttKRV
ndAI7YYVF+cOhSgvWx1VX6/OqFtc29aqzgi3hluWh2tGtdRV1c8IL26vr2rp73YkK1TjpSPnhFta
6QB52SPy1PTJddUtTa1Ni9qGsFoXvmQFk2ex5DF1VktVTbihqmWp2rTov85abQkvrmttC7eEa9S6
RrUNqs6eqU6ralOD6qzJ6tRFi7LVqsYaNVzfGl5RC9WyB3qC9TYtbqlqrl11YVFYHdtStaKucTFt
WweoHarOaFoIXU+pq65tqq9qzaK9t9RV11WpM6vaG2tgDYCmEXljmhrbwg10bi2r1NYqwCAgqW6R
WhNurVvcmKXG8FINtarq4GVDU0tYrW1vqGqE6avVtVUtVdWwDMjUVbfCOqoaVXi3iq6/DlDeDAsM
V4dbW5tgOLqgKui/vbpWrYt3RRff3hhWV9S11TI0NDQ11dDWFIZpt8FEqgGprf1lbSvCjW11Yahd
DUB7y6pslWG6aXm4pQpo3dYSrmprgFe0QXU70LuVDkapF25hU1jUXl8PIJsrDN/QBIPUNda0t7ax
pba2raoPX4gJyqmtdJRwS0NdI6vR0rQUuq2C+Ve3w0AxAtbUVS1uou9X1ALO1dpwfTNgpEldXLc8
zCowlq9S6wEdakMYcNdYVw3Vq5qbw4DGxuowDBJDdx1FlhpeCYtpCNevUmFtrcA79bSPhrp6ht62
+CZqjY9XDS0WhtX2VmAphs3wsnY62fZqin91URMsGXqERbW1UT6BpbeEge5twBpAplZAGWNPyDZU
La66pq4Rug63VWfFkAbNa+pam+urVtEhaOvG8IrW5qpmmBpUqYEpttW10o5p9eaWpoYm1lt2bVtb
88icnBUrVmQ3xBk2u7qpIae2raE+p6GN/tv1OQ2tC6rowrNp4f+wwYpwPZSGWZMpU2dNGDdhzKhZ
E6ZOUaeOUydNGFM2ZWaZOmr8jLKyyWVTZhlkgzyrFtDajzWKYkoTmCisoI1h9Ce2GFsMZWS65oWr
1FVN7bRlNeU2wDPbRzG2BOZgPAr0he3XCNWrFreEw5QTs9VyaFZbBWzQtJBuI2jZdtFkKHeuoOwU
BsKFKaZbwtVtQOdFgMfBeVESNi0OsyqMxAPtgDTAvQvb26BrmGYT7KgLFpTW2j8pYOQBVAw0ptym
Lq+qb69aCBxW1QoccmHrbHV2I+PZVf2rgDXFJRewd5Xa2hyurgOh8+OVq4DFRsZttG1VTU0d5Qng
yhYmkbNocQvDLdvdP5hUfV1DHV0QDMLqrWhqWdoaY1LGj6ywaQUI1PaF9XWttXQc6CuG7gZgVJg/
kKp5lRpj3jiGLh6I4WPCosHFUem1rD3cyoYBuVcdbmmMr6AlPm9WubW2qb2+BvbQ8rrwipi4+tHy
aT2gZBgkQM2giBtYI0yLCdbqtkEa04VVxWe96Ke7ZVMeaBDf9/GOYJyqtpG0wuyZo0AJpI8oKBqi
Fg0bMTS3IDdXq509EQpzhw0rKIC4KL9ILRpeWFxYbJD/w677r5uR5nLi02P7EFzVJubkUaOcumir
sAEU/xIwAL5kZkP/u5nMDKJOIjXaarh7uD3cc9xhCAe4g9yTPx/p/3ykj34+0v/5SP/nI/2fj/R/
PtL/+Uj/5yP9n4/0fz7S//lI/+cj/Z+P9H8+0v//4JH+RZ7/IFzF6v/Uu49/0CZ80ZkAOxX4D33W
Mw6/IM8n88P4ifx4/lKIiy8agcrg/9TLFLZnqOyJrb4Wd+IHOMT2xX9u89PwwF1eFE2jN/p//DPK
j0ycA30NIQqBQ16IcyBMhbAAwhYIOyBoWD1a0gRhLYTDEM6wNyHO0XVHfqgHkltYsndJfR7LVsWy
8ytYdu+V5bF08vRYOnZCrNrIWLVhBbHi7NGxNC0rlloCeR00lQ15vaPsnB0d5ejly2aIMXkRmTBG
XrSTS0CdEAiniZeEOMve1GDejsMcjzBHOAw49UZ7OdxlMOeNkkmUfI0syEv+Rk7H3pDTe43mvB2j
riB/RrshHIbAkT/D8zH5GK0lJ+nfa0JcCmEHhMMQjkD4GoKGnITnBDwfkY+g1ocoB0IphAUQdkA4
DOFrCCL5EGKF/IneBmYxhUshEPIniBXyASzrA4hN5DhAx8lxmNpbXUXFeQcYkJkTB7yBOOBIjAMW
e14P+WPXt0O8PeSTvWqmd+eoXPI26oRAYLC3ofO3kQphGoRKCM0QNAAdA+gY6oCwFcJOCJ0QNNDm
GLQ5Bm1eg/AGhGMoF0IIwjQIEjnaBcP0kCNdwdHeUXbye/IycgBS3ySvsPQN8hJLXye/Y+mrkCZD
+hp5qSvZi0bp4D2CNgqkCqQ58F4gv92bavFGR5nJYUCPF+IcCKUQpkJYAGELBA05TFK6arwW6OQQ
ek1CULMLfcnSR9CDEgot8YaCY4DHVBoFR14KEEQ71B1BEgpu2w5ZGgVvuwMgGgVv3AwQjYLXrAOI
RsH65QDRKFizBCAaBectAIhGwamzAIKoh9z/TGqat2jqUqyOMpEVgKUVgKUVgKUViCcr6IO+5enc
7u3KyACM3RPKHJLh7TiIO57FHTNwx4O4I4w7rsMd63BHCe64Gndk4g4P7kjGHSHccQiPAFR04FD3
RdnikBN3vIY7nsIdrbgjiDsCuCMVd6i4KNRDfF0T8llSxpK9o+i+gvTSy/JMMEcfYNQHbO2DbX8Y
4iMQoiwXgkpqSqyyK5mmKXszSmP57JF5TaMuJy9AwxeADC+gExB4INALwEYvQCf0droJ4lIICyD0
QvgaQhSCBmqnwMS3sNgEcQ6EUggLIKyF8DUEDZvO1xAIaopPcTebWE580lNpjrwAD/3fRn3EF0pS
PEqmcjm3xYNNyXhqcjSZFCE7/esEi1ky92DD/n8Z/v0vA9KO0pLbyBaUBITYGk+3dH2b5O3Bd3cF
D3lHJeC7UDIPXIeLURAHIB2BWlm+EHkkmhYgD3kC0rwuzxwv/XPEYJb3IDbSVvu933pOeb/09BAA
v/Ac8r6r9vC4y/sOlDyx3/u252bvqzk9EpQ8G+zBkBxUWdUDnhHep15jVdfBi3u6vNfRZL93jWe8
d6mHvQjHXlzdCrmQyTsjOM97OfQ31rPQG2qFPvd7Sz1Xe0titQppm/3eXJhCZgzMgMkO8bBB/cms
w9lFPbg2lCVuE+eKU8XhYp6YJfpEr5gkJoo2ySIpklHSS7IkSRqJl4iEJBv9q7xM+scVNo3C/i0w
nsY8gxVCYxL7OxOCJYKuQJ1WbiKZOHM0ntjZW40mLlQ7z83092B5+rxOwT8ad1omoomzRneOyJzY
I0ZndBZlTuwUp101dw/Gt5VDaSfZ2IPRrLk9OEqLbkqk/1Xigf/V2Bn0pg1DcdxuJpWMMZUdaFQC
CgqZpkbdpAkJrZmAsmQccmErqvCUQyhC6m6TAj1WXHpAU0+TdtgnqHZyxqWwy858in6E0S/QvecE
aDUmzcJ+1v/97IeNSZxDZEJp+vwii/bZ+QVjRMmcVpXqk0r61Vt7TeHH5Z0345R79Rz/6h62+fcc
4y+xcptjLv+CZylO6A397dgTOkfD2hOpQm+c96hLFZsx94oeCY5odA4crJi54BJ5oiFHtEQ+4r5F
nAHtgSuiAU6WiSE4Q5YF94AiFwZFxw6LRcFsw9ZTMMG2dpeZGcAYhmAyQzITzCwzRIZXBKKqgORV
gdAdogpEpTsCOVohL2JktERGIpJEV4waManrBZO6Bsb839SrmyYdW6zr4TmUvu70IPv88+mJwofH
mhZ2WXxA5VP/uHuCttPjTO/ZvKvbWmh5a9weui3dDonntNqhV+vZP6ya5egdm40bzVL5XqzRMlap
uaazJnZWwliN8hp3Gd0NjFXGWGWM1ag1RCwi1nizHSZInb3xIjveSD6E9epnC6ye2fpUEYvXKihn
2SlsSC5J0mT8kV7nKcjo2jvYO0AX/KfQ9RgPG41dyplVyE7pZezaAjmt14nZHwQDojgf7egTQAKp
P8AJj0oz+FcCn8NrHTvoE+Ly3UOXV999aIebm6D6OCS+v9CSSefq9lckPgdxH0VJWoKovUZNlmPw
799/sHq1dQIbjZ9jWstTeKhjEs+7rQ24FLTiUx2nsF3C20PAYIABNWmw6EN8bRLVCY53kfuDuBbP
Qz+2UStoEiymY5mgDVyq/gAhdOLCCmVuZHN0cmVhbQplbmRvYmoKCjYgMCBvYmoKMTkxMjAKZW5k
b2JqCgo3IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQ0FBQUFBK0FyaWFs
TVQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy02NjQgLTMyNCAyMDI3IDEwMzddL0l0YWxpY0FuZ2xlIDAK
L0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMzcKL1N0ZW1WIDgwCi9Gb250
RmlsZTIgNSAwIFI+PgplbmRvYmoKCjggMCBvYmoKPDwvTGVuZ3RoIDQzMC9GaWx0ZXIvRmxhdGVE
ZWNvZGU+PgpzdHJlYW0KeJxdk8tOwzAQRff5Ci9hgRI7iQ1SFQlaKnXBQxQ+IE2mJRJ1Ijdd9O/x
nTEgsWh0nNwZn7iTfLlZbfww569h7LY0q/3g+0Cn8Rw6Ujs6DD7TRvVDN6cVX7tjO2V5rN1eTjMd
N34/LhZZ/hafneZwUVf3/bij6yx/CT2FwR/U1cdyG9fb8zR90ZH8rIqsaVRP+9jnqZ2e2yPlXHWz
6ePjYb7cxJK/wPtlImV4rUWlG3s6TW1HofUHyhZF0ajFet1k5Pt/zyonJbt999mGGNUxWhSVayIb
5roEl8ylAVdy34JrZluDLbPjjBPm2lvJ3IHvhNfge+FH8AOzKcBL4RV4Jftq8KNwBV6LAzx1Ic5L
cPLHvlr8LfJa/C3nxb/EXlr8S86Lf4W9dPLHe2nxd9xH/Eu8ixb/mvuIv2UH8bfcR/wdzkqLv2MH
8a/Qx4i/Qx8j/hY+Jvmj1oi/47z421uw+Nc4c5P8cW4m+XNG/A32Nen8OZPOn2uT/wM4nT/+IyP+
Fd8X/4rz4l/WPFRpejBemP+fsVXdOYQ4svyR8KxiSgdPv9/RNE6o4t8374vZNgplbmRzdHJlYW0K
ZW5kb2JqCgo5IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NB
QUFBQStBcmlhbE1UCi9GaXJzdENoYXIgMAovTGFzdENoYXIgNDcKL1dpZHRoc1s3NTAgNzc3IDY2
NiA1NTYgNjY2IDU1NiAzMzMgNTAwIDIyMiA1NTYgNTU2IDI3NyAzMzMgNTU2IDU1NiA5NDMKNTU2
IDcyMiA1NTYgNTU2IDU1NiA1NTYgNjY2IDU1NiAyNzcgNTU2IDY2NiAyMjIgNTU2IDUwMCA3MjIg
Mjc3CjU1NiA1MDAgMjc3IDUwMCA1NTYgNzIyIDgzMyA1MDAgMTkwIDgzMyA1NTYgNTAwIDI3NyA2
NjYgNjY2IDU1NgpdCi9Gb250RGVzY3JpcHRvciA3IDAgUgovVG9Vbmljb2RlIDggMCBSCj4+CmVu
ZG9iagoKMTAgMCBvYmoKPDwvTGVuZ3RoIDExIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro
MSAxNzgwPj4Kc3RyZWFtCnic7ZTLbxtVFMa/O2M7aaFNHEzTRRWuaYF0QYiL1BapElQVQZVSKjXG
KFIkOhmu7WnmlXmgOpvEbEBiw7o8arcgsWilSl2wYcGiS7pqdyyQEFsWqLBgkZZvxtdOVCLxD3At
3/mdc7577pn7mCRKFfZjCyak7VlhRQiw3QLElP1RIlczC+JHdoWW22lWPrn/iPY92pfbyvrw1+U/
ZwHjGO2TbTo+3n5/jPYK7WNtL7l6GSv7aW/RHncD26pgnmh8yq7kWVfDMhYy+3N20rc8Nf7d7Z9o
3+F0R8MgTiq48oTSh1k8KwR5eXiWWMrt/9sqDHQBs1tqche5+q+Xq+WXquVq18T2poHHKDX/vtYt
NrlavwDFzUIPB4CqfOXlyVMnq3L60ORYyXz18R/Xe73rYkIcuHnjxs1+z5jp9fv97d/6/XyVxZHZ
2mL6zQcTZ/7CM+P5xPcajxq7CylusgLuM+sZNI4ba2xv7pI8vV9GAeiWVrK6MDgamcLAQZ3DwHDP
3xqNeVF8PcozM8opeIpnNBtchVnNJv2vaS6Q39Bc5Bk6p7lE/8UBszuMZc0C+7Cu2UAZG5pNTOKz
wark+i80Z/q7mg28gB80m5jCz4M3Y1fF75qpFwc1G5gW05pNlMVczia758WbmgXGRV0z6xErmk08
J7ycC+yOiC3NWf4vNRuYEt9qNqn5nisjCvtonxEPNAtUjAnN3APjqGaT/prmAvltzUUcNpY1l+hf
n7WPyxPz86flUurLC44dBXEnTpQXy/O+PXcxVP5Sx1sN3EuqlbpWtOPYoYaKYifwZW2uVtvxnnVd
We+EQSuywrZjywVlJWmk4kWnNQAtUKPIucDzmGYkWAh8O2HiWCajPOvprgz1IE1ULJv/pZPvxaly
3XxKNRQ1ndhuK77ztZbr2O015STKHw7xc+XZNN5QjPmp34qtiPF3g8izGBnpFlJ/g1M7su7orEy6
qAbRepokSlI+VA0DMnS+knzd1Hf+XZJcU76norWnq6FIjULvKE8pn3IrDJXrXFnbVRMvko3j/Pie
4PWcx2nSElL4fF6Aw1iEADE6/CdQ8PiUOM+4jTleqpA+nyM6jKxS6eISPS1mcGFx7F6KvXwNeiLm
dmhlc9eYvcbfXlqeyLw9afGbskf7B3wVNPMKZW5kc3RyZWFtCmVuZG9iagoKMTEgMCBvYmoKODY1
CmVuZG9iagoKMTIgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9EQUFBQUEr
T3BlblN5bWJvbAovRmxhZ3MgNAovRm9udEJCb3hbLTE3OSAtMzEyIDEwODIgOTE2XS9JdGFsaWNB
bmdsZSAwCi9Bc2NlbnQgNzk5Ci9EZXNjZW50IC0yMDAKL0NhcEhlaWdodCA5MTYKL1N0ZW1WIDgw
Ci9Gb250RmlsZTIgMTAgMCBSPj4KZW5kb2JqCgoxMyAwIG9iago8PC9MZW5ndGggMjIyL0ZpbHRl
ci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2QQWuEMBCF7/kVc9w9LFGhNxGKZcFDu6W2PyAmow3U
SRjjwX/fMWtb6CGBl/e+5E102z115JN+5WB7TDB6coxLWNkiDDh5UmUFztt0qLzb2USlhe23JeHc
0RjqWuk38ZbEG5weXRjwrPSNHbKnCU4fbS+6X2P8whkpQaGaBhyOcs+ziS9mRp2pS+fE9mm7CPIX
eN8iQpV1ea9ig8MlGotsaEJVF0UD9fXaKCT3zzuIYbSfhiVZSrJ6aO/Z43Sn9rF+2oBdmaVJnj1X
2B/3hL/fE0Pcqby+AYr0baMKZW5kc3RyZWFtCmVuZG9iagoKMTQgMCBvYmoKPDwvVHlwZS9Gb250
L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvREFBQUFBK09wZW5TeW1ib2wKL0ZpcnN0Q2hhciAw
Ci9MYXN0Q2hhciAxCi9XaWR0aHNbNTAwIDc5NCBdCi9Gb250RGVzY3JpcHRvciAxMiAwIFIKL1Rv
VW5pY29kZSAxMyAwIFIKPj4KZW5kb2JqCgoxNSAwIG9iago8PC9MZW5ndGggMTYgMCBSL0ZpbHRl
ci9GbGF0ZURlY29kZS9MZW5ndGgxIDE5OTE2Pj4Kc3RyZWFtCnic7Xx7fFTVtf/aZ88jD4Y8eAUC
zEmGQCBPAgjEVCYkE8DwCBAwod4mJzMnycAkM84jMRYLXmu1QYu3pbb2IdgWtUXLZKI2oC3UX9t7
tQ+wra3tzwr+tO8XtWrbW83c797nTB6A1t7f/eP3+fyYk7X32muvvfbaa6299jlzGKLhmE5TaD9x
cnt7tNB0xgif7xCxXG9fVH3wuaZc4OeJ7N/oDHX13PW5m18gSv8CkTXSFRjo/MXH33+EKCsPY/q6
dc33yKrsqWjfjfZV3SCsHx2wo/0faC/o7oneOJetTkP7d2inBYJe7Wq6GmjWayhsPdqNoe3ZC61o
v4m22qv16O99JuuHRNlzicpjoWAk6qMFSaJrDon+UFgP/WVR5+toP2rqwEiqjxURs8n2/+cf60cA
G8kJmMsPUT5R8iXAK4BfjV6bfNO6h1yju5Pn+TQwP2ICURHdQ4dpAV1gS+kpOk3X0gNUS010iNbR
GTpOU2mAfZss5KJ6eoiKmJMUaqBZzEr30k/oegrTz+k8FVMjvchyIcdDIZpJq5O/RtlIdyRPgCuD
6ujLdJIF2HaqAL5eKWUlmPlg8jTNouLkd5PPo/VZ+jlbkByi9cB+QTm0iPbRv1Eu7aZnkiJKFlAH
Pcj2sl9TAbXTActyy2ByD4LqMXqONQLbRAPW59MfowBGfZ7NYqeT55K/pK9ZGOmQ9K90BzRO0Gml
nNdZj5BKC+k9tJk09L6ffsKmsaXcnVyUXJu8F9QH6VWlRPkWt0OPEtpAbXQX3Q9r/IheoddZJlvB
PsuO4XqW/cH6PHRrpBjdhL31WVjvQXqYTrClbKkyS5kFa82ixbQDfQfpKOYfprOskbWy0+zr/Ki1
cnRNcnpyRvKXySQtoRZoeJi+jjleY5XgwQy8kEct8y1Ra9Vbt2CFPvoMnaVnoceLsPvr9Fe2BNdL
ygeUfcnrkg8lfw5d0shJq2gr7aIg9VE/fQ5efYq+QX9if1fSwXnG8k3rTdYLyY/CtgtpLXTfAu7t
kH0AXkrQCK4fYZU5TMUqVrHNbBvrYgfZPWyE/YT9RLEpBcoNym94nH+bv2C5ympNVkPSTJqPeV10
HXXDAx+AtT+K9T5E36Sn2Qy2kJVhRT/C+DeUq5V6XJ9Xzigv8tv4Qcub1g+Nnh/97ejfk4NkR5St
gx1i9CVY4Y9sJnRYzHazCHsZmt+tPMqn8mzu4it4LW/mrfwOfoj/B/+eJWw5ZvmpdYNVsx6za6O9
o88mG5MfJJEVbNBrEZXSclqJ+OlENO2BfiFcYdpLt9AgfQTx8lE6Qsew7lP0ND1HP6PfwQPECqCz
H7P3IOpuYx/BdS97mH2dfZM9zV5ib4hLKcRVrFylrFHqlAalS7kN1yHlrPIj5Vd8LvfyfXw/rvv4
4/wnFrJYLElrFa711gPWB23fthfb19s70r7z5u/fWvJW61svjtLonNH3jt4z+vXRXyZ3JgegfxGV
UTk0vR1a3osYPIrrS4jEx+lbyN0/lrq+yhRmRcTnMReioRReW8PWsQ24NrGtuHbguo7twqWxDtaN
ax/bz/6V3co+yO5iH5fXJ7G2o+yL7HFcX2EncT3HzrFfsN+wVxUEscIRzUXKIqVCWY2V1inrlC3K
NlxdShBXSAkrffDQg8qwckL5EZ/Gi3gZ1/gN/F7+Zf4U/yH/m0WxlFoqLDWWnZYuy62WM5ZnLc9b
/m51Wj3Wbut91qds+bblth223bZP2o7bfmV7026zN9k77HvtP7Qn04qQrf4d635sUsqrsJ1hEet0
y43KOeyLPB6y3s52wGI2pZkH+Ef4962d7AJX2U/ZIPfzPcnP8wblrzzIdiqnWCF3Wqt5J91JSXZM
eUl5TfmlZQZrVn7Nii3/xr6iBHmdYpN59QeWGZZbrb8iUn5M1crN7LTyTX4rvzX5Vaq23sfOWe9T
niXVcl6ZRuewq29XPoFB31P8ygFqsSy3/p38sPsXrTfC3tcod7Al/IeW++jn3KX8mV1g9yBrfJdd
a1mgvE9ZzY4h477F5tPv2Q0UYh8nN3uC/YyNEGMP8QfZRmUKvBVXHGwlDrvv8gL2Q55BrUJHtlCZ
wZqUC8oO/qTtLF+Bo/0sfZ9uYpxVInZSn1HqxQ44pCxCTvMgm/yAVVEefQL5/rXRJ0XGtj5vPYA4
u5+X0jaqpH9Rvk3V2Bs/x9VCH6IqOokYvIMqlU/S3uR+5kPe34T8qdAI200VLBPZchZ024fzYqZS
iFzYhln/ivz/DLJ+I/sD9TMVO+s0FVtEz50WDzJTO/LvAVw++he0PkMftT1m/QFtYbOILOrofYjy
F+h9OHNexvxzqAb67aL7LaXQWkVmvgEjPjO6nty4PkTfZgrdDJ2vwT5vsqxH5r0nuRsr9OOM2ogz
8WnyJz9BdfDdtuStyQPUlrw/eT110fbkQ8i/fckEXUW3W1uVndYSy3Lk2KfZN3Ae/W92AHl7Pf0U
+aiI5dFvcH0ZGl1jfYIGLT9G7lyTvDP5HM2APQphoQ6coq9QD/0BdlvPT9Oy0c3KULKBh3BCnaOt
yQeTTpZB3ckAMu+TdNRuRe7ZT/OtR91u95pr3lNzdfXqVSuvWrF8WdXSyorystKSJYuLFy0sWuAq
LFCd8+fNzZ8zO2/WzOnTcnOys6Y6pmRmpKfZbVYLVxiVelwN7Wp8YXvcstC1fn2ZaLs0ELQJhPa4
ClLDZJ642i7Z1MmcbnB2XsTpNjjdY5wsW62hmrJS1eNS49+td6kjbNfWFuB31bta1fjvJb5J4ndL
3AG8oAADVE9ed70aZ+2qJ97Q1z3oaa+HuKHMjDpXnZ5RVkpDGZlAM4HFZ7lCQ2zWNUwiyixP9ZBC
aQ4oFZ/jqvfEZ7vqhQZxXuTRfPGmrS2e+vyCgtay0jir87o64uRaG88qkSxUJ6eJ2+ridjmN6her
oQPqUOnpwTtHsqmjvWSKz+XTrm+Jc61VzJFTgnnr47NueiVvvAnhuXUtt0/szeeDnjy/KpqDg7er
8SNbWyb2FoiytRUy4kpRQ/tgAya+EyZs3K5iLuW21pY4uw0TqmIdYk3G6nSXR1Dad6vxdNdaV/fg
7nY4Zs5gnLYNFCTmzHGfSJ6nOR51sLnFVRBfk+9q1ernDk2nwW0Dw7Pd6uzJPWWlQ9k5hlmHpmaZ
yBTHREQf65OYZBdY47YxuzKhkWsDwiGuelVo0uLCmlaJQl9Fg95VYMOnlWFU3Ad/+OPpde2D2dWg
Z4vxcWtRtksdfJ3gf9fvfzeZopkUW1H26yRQESVjgYb+FB4vKYkvWSICxF4Hj0LHa2R7RVlp34gS
d4WyVVQwHzXBtlprdQWMX1Ag3HtgxE0daMT3b20x2ip15CfIXVHSGlfaRc/pVM+MHaJnf6pnbHi7
C3H8qHz+mBFPWzj2l5U9c5qnuzrOZr5Dt270N253NW7d1aJ6BttN2zY2T2oZ/avG+kyMGR0weNxS
BEttcCH0tu1qEQT8WYsaXB5/+3psNegYn1bXwvOVVgNT8rkUhfi9fkyyaLRMEbIsRTYZ/74RexoC
WFKY2hDPbl9vlK0ZBQXvctBI8oIYJavxYeaa4tUlk9tXT2pPUm/KIIfCloVKY/OuwcGMSX0NSFaD
gw0utWGwfVAbSe7vcKnZrsETvIW3DIY87Sn3jyRPHsiPN9zZikV0s+oyHOvCN1ZceDK206YhhT2h
fA33jXblVIKslhHla49yyrAL5DFGs9Ns1lPoV4izxZTO9rD3UV5J9hs1b9Vszn6tZtNbNbQGePab
KJZWFuQU5BShYDgR31T56TfdVvo77hZOk/HEqjz7u+c+/UxrW1bN62mz0+Qh/bmX5z016blOaIYH
8bEnXNT2glEP7rRpnDLpo9hWs7mKgRuP3XIuPBkYRIWy8RxWC9nfxbM0l9R1fBcJCxj3CWTiDHfP
oyau0FQ218Q5hdkSE7fQfPYZE7dSHjtp4jYqZN83cTs9z14z8TRaqHzHxNPpQ8qrJp5h3clvNPFM
Cqd9z8SnUGe628QdtkfTHzDxqXR99q6xte/LftzEGWXlrDBxhew59SbOaXVOo4lbwPNBE7fSlJyP
mbiNcnIOm7idAjlxE0+jablzTTyd6nIrTDxDOZYbNvFMWj1j3ti3Estm7DRxB98148MmPpXK816G
JswirD5ldo7ErcIjs+dJ3CbpZRK3S/pqiadJfIPE04WPZreaOHw05zoTh4/mxEwcPppzq4nDR3Ne
N3H4KH+aicNH+SUmDh/lbzJx+GhukYnDR3MbTRw+mvusicNHhYtMHD4qvNfE4aPCpInDR4uHJZ4h
1rUkS+KZYi1L8iU+RdINHaZKfKXEs8ValtRJfBrw3CVbJT5d8nglPkPKCUp8pqTvk/hsOfaAxPMl
j6HbPMnzRYk7Jf6YxBdI/q9LfInEz0i8TOI/E3iaof9vJW7M9ReBT5H0Ei5xuZYSucYsET9Ukk/N
NIBnTR333Rp5Uav0RUAznpIFvgnP6L2AqMml4j45iCfTkCw10P2SQwUlgPHlwOolXfu/lFQxppmK
+9cgaLExnoi8s+4151tKq3FV4jnUwKoktRYjAqi3YUwXdIjKUdsgLwIIUx9KH+bw4z5Yl32bUfdL
niBoGuQL7i7MG0ArfMkKqv/BaPWi8dW0U84cGVup0HQVSlU+p/ixnjB6IoBOzLL4H8h/O2njo4wx
4yOaYMlN6H9nuV+WXhM+8aGvR+q+BzSh1X/fnyqowhp+zBqVmgv7q2gLnqgpdQc0VKGnGC++ARPz
bUK5BXN3Sr8KDcU4HVIjUvduU1r5ZXQyYiiIeYVOIfAOvC2XLmNX8PVLrbrG5vWbO6NMxmJU6hAA
ZcC0Q1iuSkgtBWWn5I9KuoqnOmE/YcleuSYRo8ukl7rlKMMuKStreDYLyLmil+xLoUdYWk+VaxG9
2kV2TElPtVPemuhxw48bpb4+00e90pIRyNSk3LBcSae5hn6pqxelkBuVFE3K8kmZYof1Sj2Eh8Te
FDzdJk8EO6BD+uoGYIYdAtJ2HWh5ZdzpUq9es+6cEBH9UocAZAtZPXJ/RE2pXmmZCK5OucvUCT71
SstoE3KGoVvKIobXuqSdNDnWN8n3ETm3EVmq9I9PYjFpNV3a5Z1jYZFpIb+U4Z2wIzok9zvHibED
LvXfRAsbNuo1Ne0do4ksEpNZTzUzkU43yl3XK73VJ2X6zX1o2MigheTYlFWNKOqT2bdvbE8IW4fN
ucNjHtozFnMX7y/DDu9ujxmrWysjx4jr4Jj+Rlwadug18/lkixsx55PeN6I7Ji1sSIrJtRtzNklZ
QmIUdG1CXmmS2bpX2sTYz/5J0WzkyAGpWUCOiMiVBsyo65Z+1Mx5w2a+E6uLSM/HJu0foa3YcSkd
RTSoMioNf4h1e2WuC4x5OGDm0Q5AQGo3YK44JnOtIalf9nRLaUFcRs70mr7pwRjD1teBzydnGDBt
NDGfdMixe0xdDQsJC3QBbpI8IlIm5goR68YZEDV7gpNyqE/GV2ySF1OSNZnTgxOk+aT9QtInA5M4
fdJCYWnblF/L5TkfBX817h8qYANxlcusMTEiy82sUyH5eyC9AmVUZgKhl2hFqE3KNnadkR/DY2dk
+djI/9kZ+6UnUjlxfJbN2CXN2PUNgDrc2wh8C6hi9zTI7CHoHlC2oxR3P+twonvkt6iC2kwOypAw
fu5cesKk6N0TckHItPLAWGZ+d6fsuK/8ppeN2EplvwEZr6k5vfJd0PhdwcQsm9LH2E89E84wTe4G
I7J6Tema1EKXZ6oRYSLOW83ZxO7sM/N/h8zefvPkMuZ5O8uk7sn6zRNX7CX/hBw4McsbO6nTjJbL
2StorktYTJ+USVN79tL5fGYmCcudHxvLGB2mZyaenZfPwJMtZZwll0bFpTP7zT2qwnKavA8fv0vR
5Dmhy7x0+bmF9XeYZ6Rxpgxc4gvDT5PvCY1MqEmNQtKyfjOLvBufq2YspvJ414R5Re7wSUsb57Fx
+ocnPCeUjnGHJ8Tt+H3JO1sqILOG/6KcPi4vdV5GZPyN3xWkct44ZxC8xh10TFpcyO8eW4+h18To
7jGzpGF/Y1eFzPgYz6aTY+idVjQeHxvk2i/1XOosNO7sIhNWY5w0XunV3ot8EL7I3uOSxfqC8l7O
Z54l4r7DeEJJ5YF34/2UPGNP6uZ5OvlcTMm71I+GtYwVRM2z/HL7OOUx7SJbd/5T2o5b+dIZvOb9
W4fZmqiRbp6EUZw9KQni+Um8dxJPKsV4GhRvlRcDX4kng1WgVoJSiUt8a7KDGk3OSvQuRc9yE1+J
Z4iVctRVtAJPFAKE9H/urPvvn4ypvoqLrDd2HjYPhPROzaurX1Sbu3V1U7A3GAVJrQuGQ8GwFvUH
e9VQwFuu1mtR7R8wVQhh6vZgICYoEXVDL8YtXb26sgxFVblaGwio2/xd3dGIuk2P6OE+3dfs79Ej
6ma9X90W7NF6t+ldsYAWTk1QfVG3avZX79TDETFpVfmqKrV4k98bDkaCndHFF/FPZJNd6JEdTds3
NV/E+5DaHNZ8eo8W3qMGO99xnWpY7/JHonpY96n+XjUK1h3b1SYtqi5UmzepWzo7y1Wt16fqgYje
3w228jFJsFCwK6yFugcmknS1Pqz1+3u7xFg/nFGmbo9qvQF9ADqE/ZFgb6m60++NBsPqRi3s03uj
MOuyquZufwS6CJW1joCuRlO+7PSHI1FVC4V0zdRRsItaLMtYONa4Mdjrw4p69f5ISAvp4VK1EzP0
d/u93ao/qvZrEdWnR/xdvbqvXFU3RNVuUCKxjoh+Qww6BAbUDt0b7NHVYK8u5AlD9AfDAV9E7QlC
gUjM69Ujkc5YQKqmesO6tGEE0oQiWFqXv1cLqD5j9RG1H8ZSe+AGNdbr08MXW2ERFPKHda90RMfA
xTaBA8bWZygMjXohtFdg4WCsqxt+UfUbo3pvxN+nY5G68CqwUDgoVIWJ+oKBPuGJzlgYo8NiQXuE
5VL+gg6X8RimW6tFYOugkA9bQodexLmpOCznU70wd8wbBVMsIkY26eGQHo1pMlaaAlpv1A8/+w0z
IyIH1GDAp0aiA3Ctt1sLaxgLaVG/N6J2xAz/aD4tJCRGg2qXWId+o1cPBMSCA4jRDn/AHx3AxLFQ
AEz9/mi32hUMIjKhS7BnAFpf5/fpcGQsYsRJRzC4JyIV6tG6tJv8vXrEiIqwjh0QRSNoRKgv6I0Z
SxTMWiASlGw+fyQU0AYMoq9PD0f9Yq3l3dFoqLqior+/v7zHNGQ5QqeiO9oTqOiJin8VWNETaYsK
1yEew2JHlovOdzmwXw+ISJRDNm9p3tCwoa62ecOWzeqWBnXjhjrP5u0etXbdNo9nk2dzsyPDkSH3
ztiGEXi3jAK4DhZDMF9my8pV+bFkWEuE30AwJkZ6g30yFRghK+TATz1yh2lqAMbqBbvWFdZ1YbBy
tRXDujU4K9gR1WBheG+SMiKT9WPjqrpfRqAR8nBSJ8wyrhesHQ126UaQCs+OjYMTomE/QgSioaa5
OycEsKkUdsmYKcYGA9fUPi0QkylFi0T06MTR5eoO7EjslIHUKrAmMxMiCDU1EtK9foTIpStXYUUR
411yrObz+cU+xvYPyzOhVJDD0rYyl1ykVMDf4zcjXfKJfRmJGjlZRJ4kBvuRoGMdAX+kW8wDWYa5
exCS0B+uCg2oRpiaFpo8kbTHhs7xxYldiGQXkdNg03j1cK+5grCpt2SOdAdj2Kxhvc+PA0XEwKXL
F3zwpI59au5FwTe2RqiFCaLY5eM+FgvTTK07Ly9Wqjw2wIv81qGnBGEeLVotGHZsr8WhUrxq+crF
6sqlq8oql1dWpqfvaASxcunS5ctRrly2Ul151YrVK1Y7Mt5m173jZhStClM9uQ/xsByUj5nisUA8
JA4wB249duMW5NfyxiXVl/ryz2d8ccc/xYf4V/kpwAl+kj985cXKlRcrV16sXHmxQlderFx5sXLl
xcqVFytXXqxcebFy5cXKlRcrV16sXHmxcuXFypUXK/9PvliZ9O3HOK5J/sv1vXTRGH3S9yLGnffl
ZQZkhE9oW+ZblloaLess70G5etIMIge/nZTNcs+I3GOsvpvF2f2c5L6oBVdYnnlCp7eXcHl87N+b
U7IA4i/zOZE8zV8a9niq3COoS8plnSheXCU7EnPmVn2Vv6Q8jHPCCcK5xMx82fNiYu1aE7lqlYEM
LymrOlebwV+kPwIU/iI/hziTo4aLy6su1DpAYPwDlMUYOekI/xnFAQq5+U+HFyysOnyKfwf9z/Cn
oakY9nTCkVMFgf/Ov0K55OSP88fMnseGp+ZUUW2E30WMTqM8CzgPuACwUJA/SPsABwHHARbKQukE
VAC2CAo/xo9Bz6Pin7KjrAAEAQcBFmrmXwJ9jyj5Q3w3FWLsnfwQzUB9gH9M1l9APQf150Cfj/p+
tEV92Gx/GrXo/5RJvxftmag/adafAD0f9T3yh+RO/nGz3cdjclzUrI/wSGK+M7t2PvpVQCWAAzsE
7BBMd0g4GCXjt/KAnGkIdRXqHqOGuW5OFLikj24enjW76ghMejNMfzMsdzMsdzNZ0LU3xbPX4Cnj
e8GzFzx7wbMXVqnkEcwXET9lQJkNUAEcdo/A7oIeR3kacFbSP4jybsAR0eL9sONiaPVhvjtR7ESQ
dQ2vdleteYJ3wtRu3jk8e17VwfFWeoYIRNRTzTpL8OqyVx9OnyKo+vCceUYNrj21U7mX3g9QaDrK
BYDlgHqAhXsTCyqcJ/lm6kkj91TnPmUf32fZZ7VU1rPcU7yKmtIIIZnLy6gGDIudbTVsZXt6KH1/
Os9OV9Mr093pTenWIN/HD3Lu5BV8Dd/C27h1JHk6Ya9ehsq9zla97O7MI5nxzNOZZzOtcdtp21nb
edsFm1W1VdrctiZbuy1k22+723bEln637W670p4ZytyfybMz1czKTHdmU6bVaWdHam/jHeKnDCiz
ASHA3QALbNwGusrfB2iDN9pgiveBTigJrWzAWeDnUVvRygJfFviyQM0CNUv+/iZL9jQB2gEhs9c2
1pMaI/gviB7AIvROBVX8eOA8ygsCA1yLlgMtB1oOcJ1V3oSG2ShVQBOAS9p5AKIGZaqv0uxvB9hk
/wXJk+pzi7HKm25t0enFLL6YHVnM7l7M3DVraqvchShyc3PbXG1FbcVtRy1BV7AoWBw8atni2lK0
pXjLUcsa15qiNcVrjloqXBVFFcUVRy1Ol7PIWew8ajm48fjGUxvPbLS0bQxu3LeRr4TrhhMllVWy
LiwS9WOJ2XOqVmbVvkc5juW0oTwMOAfglIXSCagArAEEAVbluKQ+AuojoD5CWwBtACtGPSJSDEqn
2Sfoh2WfwES/MqmfY/EPJ6qXbandiLTbBjgM4JD9MPofltwGdlzS4yjPS/oWk/+IpAsuJyA1TiTB
XTLd7cI23EVrAG2AEMBKZ/h1dA4A6SidgBDgOMDCd+G6jl+nPILrYeVhXup2LJ3hpJkzcXzk5qRl
12YrUxALDvaQLD8pyw/Lco0sF7inXut441rH1651fOhaxyIgSjEONgc7JMsCd2at49Fax5Zax+Ja
B6TNogJyKDNkaRMl+60sN8uy1D29wPG3AsefCxx/KnB8tsBxQ4HjPQVi3FzsYYcyXZaZomT3yPJa
WS50Zzod33I6rnM6VjodtQ52H8PstFaW82WZL0r26qNZ9VmU/gR7leohiSVqFjtHFJIVSyZqalGN
JmrWoXorUXMfqv9M1HzM+ST7G5NHG3sjseAVZ+0M9hrbYBHtP5v1n9gGOob6Auou1A9QDStC/YVE
zS2C//MY/ym0P0eFaYL/fmqS4w6zDZL+WXPcZxKlHZj104nSAcz6KSqVs34iUfoKqB9LlH4Y1UcT
pQFUBxNFQsHdiZolztoc1kULFMHrpSJFaLLRnHE9JAdQrzMGexKlYlS9mGCE1SVcS1EtElo+yVzU
JKdzJlxykfPIJUXMJZdUOp+KZD2VZUnlHVQo67SE6xZIsT1a9IrzLzVPiIXT6ywrcZ/z5Sexvp1o
/h+2IXHM+ewJYa6E80zpCCt63Pk91xPOby4YYTsTztOlI2noOFU6orDHnEMwchy8Cnvceby0y/mI
S/YedaEXrj5cU+b8tGuX894itBPOW0qfFGpQD1a8E92tpdc4N9YcczYUjTB0u2swmTvDWe0KO1eD
vGqEbRg+5ly6YESoUgkZxx53LsGMC11SlR0rTyoryM5i7lJ71N5h32nfar/avsxeZlft8+xz7dPT
ctOy06amTUnLSEtLs6VZ0pQ0Sps+kjzvLhG/n5tuy5b/dYZFlBaJZyuiVIyfEiosTcHeiU/jjUrj
9rUsnttIjc1r4ytLGkfsyW3xVSWN8bSm97YMMfaRVrTiyh0jjJpbEKCCdFu++NH0CWKs4ra78kW9
97a7WltZY/y0lxo71Pgb27GOjK274lbX2jya2bcmb03uNTmrG+ovU7SbZcn4J69k4idvXvyexu0t
8S/Na41XCSQ5r7Uxvk783PqEcoMS9NSfUEKiam05wW5SbvBsE3R2U33rGBsVKiGwUY2oBNswFQo2
KmTDkm2jZEOYFnrqhwoLDaan2AbBhPB5SjJ1GbIWYArIahIV2JT5tEDKWqDMF2yIB0NY1kRhU4hl
SWFZU0gKmyuYhoqKwFJaJFiGVhaBYahopew+Nt7tKjLUaaUiOU8Ra5XzMDbOU2zwIApMHiUNPCX/
kx997T/BzIa1F3xe8aP3dpdHB7THD/R158X3d6jqkO8F89fwC9s7vN2i1vT4Cy69Pu5z1atDmvcy
3V7Rrbnqh8jraW4Z8rr1+oTm1jwurb51+IF9dY2T5vrw2Fx1+y4jbJ8QVifmeqDxMt2NovsBMVej
mKtRzPWA+wE5V+O2tayxqWUojda21l1v1MNKZgb2Q3t+Qevamdmha+TmuLog7wP5Jy2EYyuzpDU+
xbU27gCIrrLaslrRhd0puqaK/9bA7Mr7wNUF+SfZQ2ZXNsg5rrVUQnkef/3YXyQSiQqIxUpQRmN5
khbFpi3Y3hhvED/CronXeOLu9vpWJtwRMz91Le7sUzVnapRgzb6agzWHa47XWGOxVpBzTxWeKVTa
CoOF+woPFh4uPF5oEx3Xtzzurjlc+MdCHkM0sSg+nno5Zww1/kQzGouID2GCCMCYriRWUtdSW0he
3PUy3KGX0TSAC7AMsB1gpf+F8geAlwF/BljoVpQfA3weMCwovIyXefL89WLG1hKRdPJ41XDliqpV
I6i1TqPevsuoPZuNuqa2Kg91Ys2yjNos3IAzOonyGcBPAb8B/CfAyqt4lRQeM6K2NUKREgb1CY2o
KCIlUVYChAlzRyMlJSRABDg8ANYSNjnuiUViBFPAIajAJKkRMSwm6tTnvwBzgD4eCmVuZHN0cmVh
bQplbmRvYmoKCjE2IDAgb2JqCjg1MDQKZW5kb2JqCgoxNyAwIG9iago8PC9UeXBlL0ZvbnREZXNj
cmlwdG9yL0ZvbnROYW1lL0JBQUFBQStUaW1lc05ld1JvbWFuUFNNVAovRmxhZ3MgNAovRm9udEJC
b3hbLTU2OCAtMzA2IDIwMjcgMTAwNl0vSXRhbGljQW5nbGUgMAovQXNjZW50IDg5MQovRGVzY2Vu
dCAtMjE2Ci9DYXBIZWlnaHQgMTAwNgovU3RlbVYgODAKL0ZvbnRGaWxlMiAxNSAwIFI+PgplbmRv
YmoKCjE4IDAgb2JqCjw8L0xlbmd0aCAyMjEvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic
XZBBT8QgEIXv/Io57h420J6bJmbNJj3oGqs/gMK0ktiBTOmh/94pVk08QPJ474M36Gv32FHI+oWj
6zHDGMgzLnFlhzDgFEhVNfjg8qHK7mablBa235aMc0djbBqlX8VbMm9wevBxwLPSd/bIgSY4vV97
0f2a0ifOSBmMalvwOMo9TzY92xl1oS6dFzvk7SLIX+BtSwh10dV3FRc9Lsk6ZEsTqsaYFprbrVVI
/p93EMPoPixLspKkMbUp2eN0p/axftqAW5mlSZm9VNgfD4S/35Ni2qmyvgB9WW11CmVuZHN0cmVh
bQplbmRvYmoKCjE5IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250
L0JBQUFBQStUaW1lc05ld1JvbWFuUFNNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEKL1dpZHRo
c1s3NzcgMjUwIF0KL0ZvbnREZXNjcmlwdG9yIDE3IDAgUgovVG9Vbmljb2RlIDE4IDAgUgo+Pgpl
bmRvYmoKCjIwIDAgb2JqCjw8L0YxIDE5IDAgUi9GMiA5IDAgUi9GMyAxNCAwIFIKPj4KZW5kb2Jq
CgoyMSAwIG9iago8PC9Gb250IDIwIDAgUgovUHJvY1NldFsvUERGL1RleHRdCj4+CmVuZG9iagoK
MSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDQgMCBSL1Jlc291cmNlcyAyMSAwIFIvTWVkaWFC
b3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1
ZT4+L0NvbnRlbnRzIDIgMCBSPj4KZW5kb2JqCgoyMiAwIG9iago8PC9Db3VudCAxL0ZpcnN0IDIz
IDAgUi9MYXN0IDIzIDAgUgo+PgplbmRvYmoKCjIzIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVG
RjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzE+Ci9EZXN0WzEgMCBSL1hZWiAwIDU5NSAwXS9Q
YXJlbnQgMjIgMCBSPj4KZW5kb2JqCgo0IDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jlc291cmNlcyAy
MSAwIFIKL01lZGlhQm94WyAwIDAgNzk0IDU5NSBdCi9LaWRzWyAxIDAgUiBdCi9Db3VudCAxPj4K
ZW5kb2JqCgoyNCAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgNCAwIFIKL09wZW5BY3Rpb25b
MSAwIFIgL1hZWiBudWxsIG51bGwgMF0KL091dGxpbmVzIDIyIDAgUgo+PgplbmRvYmoKCjI1IDAg
b2JqCjw8L0F1dGhvcjxGRUZGMDA1MzAwNjkwMDZEMDA2RjAwNkUwMDIwMDA0QTAwNkYwMDczMDA2
NTAwNjYwMDczMDA3MzAwNkYwMDZFPgovQ3JlYXRvcjxGRUZGMDA0OTAwNkQwMDcwMDA3MjAwNjUw
MDczMDA3Mz4KL1Byb2R1Y2VyPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2MDA2OTAw
NjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMzMDAyRTAwMzA+Ci9DcmVhdGlvbkRhdGUoRDoy
MDA5MDcyNzEyNTExOSswMicwMCcpPj4KZW5kb2JqCgp4cmVmCjAgMjYKMDAwMDAwMDAwMCA2NTUz
NSBmIAowMDAwMDMyMDM0IDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwMDc2NSAw
MDAwMCBuIAowMDAwMDMyMzQyIDAwMDAwIG4gCjAwMDAwMDA3ODUgMDAwMDAgbiAKMDAwMDAxOTk5
MCAwMDAwMCBuIAowMDAwMDIwMDEyIDAwMDAwIG4gCjAwMDAwMjAyMDAgMDAwMDAgbiAKMDAwMDAy
MDY5OSAwMDAwMCBuIAowMDAwMDIxMDM5IDAwMDAwIG4gCjAwMDAwMjE5OTAgMDAwMDAgbiAKMDAw
MDAyMjAxMSAwMDAwMCBuIAowMDAwMDIyMjAyIDAwMDAwIG4gCjAwMDAwMjI0OTQgMDAwMDAgbiAK
MDAwMDAyMjY1NSAwMDAwMCBuIAowMDAwMDMxMjQ2IDAwMDAwIG4gCjAwMDAwMzEyNjggMDAwMDAg
biAKMDAwMDAzMTQ2OCAwMDAwMCBuIAowMDAwMDMxNzU5IDAwMDAwIG4gCjAwMDAwMzE5MjcgMDAw
MDAgbiAKMDAwMDAzMTk3OSAwMDAwMCBuIAowMDAwMDMyMTc3IDAwMDAwIG4gCjAwMDAwMzIyMzMg
MDAwMDAgbiAKMDAwMDAzMjQ0MSAwMDAwMCBuIAowMDAwMDMyNTQyIDAwMDAwIG4gCnRyYWlsZXIK
PDwvU2l6ZSAyNi9Sb290IDI0IDAgUgovSW5mbyAyNSAwIFIKL0lEIFsgPDk2MzU5RkVBNzdENDNF
RDAwMEY1QTY1MkE2OERGREFEPgo8OTYzNTlGRUE3N0Q0M0VEMDAwRjVBNjUyQTY4REZEQUQ+IF0K
L0RvY0NoZWNrc3VtIC81MjI0OUY1NkI5REIyNThCODI3MDI4MkNDQ0VDRjhBRAo+PgpzdGFydHhy
ZWYKMzI4MDcKJSVFT0YK
--=-=-=--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MM66Ld071553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 15:06:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MM669s071552; Wed, 22 Jul 2009 15:06:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MM648U071510 for <[e-mail]>; Wed, 22 Jul 2009 15:06:05 -0700 (MST) (envelope-from [e-mail])
Received: from [217.214.124.120] (host-n177-120.homerun.telia.com [217.214.124.120])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 22 Jul 2009 23:06:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 23 Jul 2009 00:05:18 +0200
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: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, RFC Errata System <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Wed, Jul 22, 2009 at 10:47:54PM +0200, Alexey Melnikov wrote:
>  
>
>>My understanding is that prohibited characters are never generated 
>>during mapping.
>>    
>>
>
>Nonetheless, it's simpler to prohibit their output than it is to
>prohibit them in the input _and_ check that all other mappings and
>transformations cannot produce these codepoints in the output.
>
>And it doesn't hurt to say that we prohibit their output even though in
>practice it's best to think that we prohibit them as input.
>
>At most a sentence, to say just that, would be appropriate ("by
>prohibiting these codepoints in the output we effectively prohibit them
>in the input").
>  
>
That would be fine with me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MLva4s070600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 14:57:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MLvaW2070599; Wed, 22 Jul 2009 14:57: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-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 n6MLvO4s070585 for <[e-mail]>; Wed, 22 Jul 2009 14:57: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 n6MLvN95001163 for <[e-mail]>; Wed, 22 Jul 2009 21:57:23 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n6MLvMbf000539 for <[e-mail]>; Wed, 22 Jul 2009 15:57:22 -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 n6MLdTFL003179; Wed, 22 Jul 2009 16:39:29 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n6MLdR7U003178; Wed, 22 Jul 2009 16:39:27 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 22 Jul 2009 16:39:27 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, RFC Errata System <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
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, Jul 22, 2009 at 10:47:54PM +0200, Alexey Melnikov wrote:
> My understanding is that prohibited characters are never generated 
> during mapping.

Nonetheless, it's simpler to prohibit their output than it is to
prohibit them in the input _and_ check that all other mappings and
transformations cannot produce these codepoints in the output.

And it doesn't hurt to say that we prohibit their output even though in
practice it's best to think that we prohibit them as input.

At most a sentence, to say just that, would be appropriate ("by
prohibiting these codepoints in the output we effectively prohibit them
in the input").



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MKmdIa066602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 13:48:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MKmdxD066599; Wed, 22 Jul 2009 13:48: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 n6MKmbZj066593 for <[e-mail]>; Wed, 22 Jul 2009 13:48:38 -0700 (MST) (envelope-from [e-mail])
Received: from [217.214.124.120] (host-n177-120.homerun.telia.com [217.214.124.120])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 22 Jul 2009 21:48:36 +0100
Message-ID: <[e-mail]>
Date: Wed, 22 Jul 2009 22:47:54 +0200
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Jeffrey Hutzelman <[e-mail]>
CC: Simon Josefsson <[e-mail]>, RFC Errata System <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> --On Wednesday, July 22, 2009 08:20:34 PM +0200 Simon Josefsson 
> <[e-mail]> wrote:
>
>> RFC Errata System <[e-mail]> writes:
>>
>>> Section: 2.3
>>>
>>> Original Text
>>> -------------
>>> Section title is "Prohibited Output"
>>>
>>> Corrected Text
>>> --------------
>>> Section title should be "Prohibited Input"
>>>
>>> Notes
>>> -----
>>> Section 2.3 is talking about prohibited input, not prohibited output.
>>
>> I'm not sure about this -- compare RFC 3454 section 5, the terminology
>> and design is about prohibiting code points in the _output_.
>>
>> Testing for code points in the _output_ may be semantically different
>> from testing in the _input_.  Some other IDNA operation may modify code
>> points into one of the prohibited _output_ code points.  See RFC 3454
>> section 2, the map&normalize steps are taken before the prohibit step.
>
> I agree with Simon here.  Prohibiting a code point in the output 
> usually has the effect of making any input containing that code point 
> result in a failure, but the point is that the _output_ will never 
> contain that code point, even as the result of mapping and 
> normalization -- the operation will fail instead.  This distinction 
> was a conscious decision made in stringprep.

Agreed.

> There is, however, an error -- the first sentence of this section does 
> in fact claim to be specifying prohibited input characters.  The 
> correct fix is to that text, not to the section title.

My understanding is that prohibited characters are never generated 
during mapping.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MKin9m066320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 13:44:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MKinli066319; Wed, 22 Jul 2009 13:44:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MKibHq066303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 22 Jul 2009 13:44:48 -0700 (MST) (envelope-from [e-mail])
Received: from [10.0.0.4] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6MKiYsg028625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 16:44:35 -0400 (EDT)
Date: Wed, 22 Jul 2009 16:44:34 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, RFC Errata System <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
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.217.196
Sender: [e-mail]
Precedence: 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, July 22, 2009 08:20:34 PM +0200 Simon Josefsson 
<[e-mail]> wrote:

>
> RFC Errata System <[e-mail]> writes:
>
>> Section: 2.3
>>
>> Original Text
>> -------------
>> Section title is "Prohibited Output"
>>
>> Corrected Text
>> --------------
>> Section title should be "Prohibited Input"
>>
>> Notes
>> -----
>> Section 2.3 is talking about prohibited input, not prohibited output.
>
> I'm not sure about this -- compare RFC 3454 section 5, the terminology
> and design is about prohibiting code points in the _output_.
>
> Testing for code points in the _output_ may be semantically different
> from testing in the _input_.  Some other IDNA operation may modify code
> points into one of the prohibited _output_ code points.  See RFC 3454
> section 2, the map&normalize steps are taken before the prohibit step.

I agree with Simon here.  Prohibiting a code point in the output usually 
has the effect of making any input containing that code point result in a 
failure, but the point is that the _output_ will never contain that code 
point, even as the result of mapping and normalization -- the operation 
will fail instead.  This distinction was a conscious decision made in 
stringprep.

There is, however, an error -- the first sentence of this section does in 
fact claim to be specifying prohibited input characters.  The correct fix 
is to that text, not to the section title.

-- 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 n6MIKuci057567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 11:20:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MIKutT057566; Wed, 22 Jul 2009 11:20:56 -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 n6MIKgk0057534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 22 Jul 2009 11:20:54 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6MIKZu4022573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2009 20:20:37 +0200
From: Simon Josefsson <[e-mail]>
To: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090722:[e-mail]::LEjUDVaIagxE2FqL:q8w
X-Hashcash: 1:22:090722:[e-mail]::oHWpe1upJXoG8g3t:4qiM
X-Hashcash: 1:22:090722:[e-mail]::LYacN2E77wliMewN:ELKZ
X-Hashcash: 1:22:090722:[e-mail]::Owg7iEIm84N9KN6e:Gntq
X-Hashcash: 1:22:090722:[e-mail]::zwgyxal2XNNKsEHW:R+qU
X-Hashcash: 1:22:090722:[e-mail]::J9fTNzt9mIPOmX6K:WBma
X-Hashcash: 1:22:090722:[e-mail]::heTavqFt7IzMfVNy:H0NL
X-Hashcash: 1:22:090722:[e-mail]::efy72a2BfttoVETp:Gx47
Date: Wed, 22 Jul 2009 20:20:34 +0200
In-Reply-To: <[e-mail]> (RFC Errata System's message of "Sat, 18 Jul 2009 13:12:49 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_96_XX, RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC Errata System <[e-mail]> writes:

> Section: 2.3
>
> Original Text
> -------------
> Section title is "Prohibited Output"
>
> Corrected Text
> --------------
> Section title should be "Prohibited Input"
>
> Notes
> -----
> Section 2.3 is talking about prohibited input, not prohibited output.

I'm not sure about this -- compare RFC 3454 section 5, the terminology
and design is about prohibiting code points in the _output_.

Testing for code points in the _output_ may be semantically different
from testing in the _input_.  Some other IDNA operation may modify code
points into one of the prohibited _output_ code points.  See RFC 3454
section 2, the map&normalize steps are taken before the prohibit step.

/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 n6IKDYSF002731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2009 13:13:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6IKDYl0002730; Sat, 18 Jul 2009 13:13:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6IKDMqB002712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 18 Jul 2009 13:13:31 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n6IKCoOL012638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Jul 2009 13:12:50 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n6IKCnhM012626; Sat, 18 Jul 2009 13:12:49 -0700 (PDT)
Date: Sat, 18 Jul 2009 13:12:49 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Editorial Errata Reported] RFC4013 (1812)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The following errata report has been submitted for RFC4013,
"SASLprep: Stringprep Profile for User Names and Passwords".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4013&eid=1812

--------------------------------------
Type: Editorial
Reported by: Alexey Melnikov <[e-mail]>

Section: 2.3

Original Text
-------------
Section title is "Prohibited Output"

Corrected Text
--------------
Section title should be "Prohibited Input"

Notes
-----
Section 2.3 is talking about prohibited input, not prohibited output.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4013 (draft-ietf-sasl-saslprep-10)
--------------------------------------
Title               : SASLprep: Stringprep Profile for User Names and Passwords
Publication Date    : February 2005
Author(s)           : K. Zeilenga
Category            : PROPOSED STANDARD
Source              : Simple Authentication and Security Layer
Area                : Security
Stream              : IETF
Verifying Party     : IESG



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6IIeNsY097833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2009 11:40:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6IIeNCY097832; Sat, 18 Jul 2009 11:40:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6IIeBRR097821 for <[e-mail]>; Sat, 18 Jul 2009 11:40:22 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.162.39] (92.40.162.39.sub.mbb.three.co.uk [92.40.162.39])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 18 Jul 2009 19:40:05 +0100
Message-ID: <[e-mail]>
Date: Sat, 18 Jul 2009 19:39:08 +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: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-gs2-14
References: <[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>

Tom Yu wrote:

> This message commences a WG Last Call on the following Internet-Draft: 
> Title : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family 
> Author(s) : S. Josefsson, N. Williams Filename : 
> draft-ietf-sasl-gs2-14.txt Pages : 23 Date : 2009-06-27 This Last Call 
> will expire on 03 August 2009. This document is intended for the 
> Standards Track. Please review this document and send technical 
> feedback to the WG mailing list, and editorial comments to the authors.

In general I think the document is in a good shape. I have some minor, 
mostly editorial changes. I don't believe another WGLC would be needed 
after they are addressed.

I've already sent a couple of comments to the mailing earlier (See 
<http://www.imc.org/ietf-sasl/mail-archive/msg04104.html> and 
<http://www.imc.org/ietf-sasl/mail-archive/msg04105.html>). Here are my 
remaining comments:

1). SCRAM contains the following text about authorization identity, 
which I think is missing from GS2:

    Upon the receipt of this value the server verifies its
    correctness according to the used SASL protocol profile.
    Failed verification results in failed authentication exchange.

I think this should also be mentioned in section 7.

2). In Section 3:

   If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
   implementation need some other mechanism to map mechanism OIDs to
   SASL name internally.  In this case, the implementation can only
   support the mechanisms for which it knows the SASL name.  If the
   GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation
   cannot map the OID to a SASL mechanism name using some other means,
   it cannot use the particular GSS-API mechanism since it does not know
   its SASL mechanism name.

Is the last sentence still correct? I think this is out of sync with 
section 10, which now says:

      The output variable sasl_mech_name will hold the IANA registered
      mechanism name for the GSS-API mechanism, or if none is
      registered, a mechanism named computed from the OID as
      described in section 3.1 of this document.

3). In section 5:

   If the client supports channel binding and the server does not appear
   to (i.e., the client did not see a -PLUS name) then the client MUST

I know this is probably too subtle, but does "a -PLUS name" means "any 
SASL mechanism name ending with -PLUS, even if it is not the same base 
SASL mechanism we are talking about", or "the base SASL mechanism name"? 
I.e. should "a" be "the"?

   either fail authentication or it MUST chose the non-PLUS mechanism
   name and use a "y" gs2-cb-flag.

 [...]

   If the client supports channel binding and the server appears to
   support it (i.e., the client see a -PLUS name) then the client MUST

Note that SCRAM also says:

, or if the client wishes to use channel
            binding but the client does not negotiate
            mechanisms


   use a "p" gs2-cb-flag to indicate the channel binding type it is
   using.

4). In Section 6: Multiple missing commas in examples.

According to the ABNF:

    gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
                        ;; The GS2 header is gs2-header.

>   Example #2: a one and one half round-trip GSS-API context token
>   exchange, no channel binding.
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: n,<initial context token with standard
>                            header removed>
>  
>
Should be "C: n,,<initial context token with standard"

>         S: Send reply context token as is
>         C: Send reply context token as is
>         S: Outcome of authentication exchange
>
>   Example #3: a two round-trip GSS-API context token exchange, no
>   channel binding, no standard token header.
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: F,n,<initial context token without
>                             standard header>
>  
>
C: F,n,,...

>         S: Send reply context token as is
>         C: Send reply context token as is
>         S: Send reply context token as is
>         C: Empty message
>         S: Outcome of authentication exchange
>
>   Example #5: using channel binding.
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: p=tls-unique,<initial context token with standard
>  
>
C: p=tls-unique,,

>                                header removed>
>         S: Send reply context token as is
>         ...
>
>   Example #6: using non-standard channel binding (requires out-of-band
>   negotiation).
>
>         C: Request authentication exchange
>         S: Empty Challenge
>         C: p=tls-server-end-point,<initial context token with standard
>  
>
C: p=tls-server-end-point,,

>                                header removed>
>         S: Send reply context token as is
>         ...
>  
>
5). Section 9 says:

   There's no requirement that any particular GSS-API name-types be
   used.  However, typically SASL servers will have host-based acceptor
   principal names (see [RFC2743] section 4.1) and clients will
   typically have username initiator principal names (see [RFC2743]
   section 4.2).

This might be trivial, but I am missing the following text from RFC 4752:
   ... targ_name equal to output_name from GSS_Import_Name called with 
input_name_type
   of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.

So possibly reword this paragraph to read:

   There's no requirement that any particular GSS-API name-types be
   used.  However, typically SASL servers will have host-based acceptor
   principal names (see [RFC2743] section 4.1) and clients will
   typically have username initiator principal names (see [RFC2743]
   section 4.2). When a host-based acceptor principal name is used
   ("service@hostname"), "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.

?

6).

> 10.1.  gss_inquire_saslname_for_mech
>
>    The C binding for the GSS_Inquire_SASLname_for_mech call is as
>    follows.
>
>       OM_uint32 gss_inquire_saslname_for_mech(
>         OM_uint32     *minor_status,
>         const gss_OID  desired_mech,
>         gss_buffer_t   sasl_mech_name,
>         gss_buffer_t   mech_name,
>         gss_buffer_t   mech_description,

Do the 3 output parameters need to be freed?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6E2LIpX031930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jul 2009 19:21:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6E2LI2Y031929; Mon, 13 Jul 2009 19:21:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6E2LGZ4031922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Jul 2009 19:21:17 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n6E2H9xu026278 for <[e-mail]>; Mon, 13 Jul 2009 22:17:09 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n6E2H8VS027094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 13 Jul 2009 22:17:09 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n6E2H8YT026433; Mon, 13 Jul 2009 22:17:08 -0400 (EDT)
To: [e-mail]
Subject: WG Last Call: draft-ietf-sasl-scram-02
From: Tom Yu <[e-mail]>
Date: Mon, 13 Jul 2009 22:17:08 -0400
Message-ID: <[e-mail]>
Lines: 16
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message commences a WG Last Call on the following Internet-Draft:

	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-02.txt
	Pages           : 33
	Date            : 2009-07-08

This Last Call will expire on 03 August 2009.  This document is
intended for the Standards Track.  Please review this document and
send technical feedback to the WG mailing list, and editorial comments
to the authors.

-- 
Tom Yu
IETF SASL WG co-chair



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6E2HFs4031638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jul 2009 19:17:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6E2HFj0031637; Mon, 13 Jul 2009 19:17:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6E2H4uh031625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 13 Jul 2009 19:17:15 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n6E2H2iV026232 for <[e-mail]>; Mon, 13 Jul 2009 22:17:02 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n6E2H1Ps027079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 13 Jul 2009 22:17:01 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n6E2H1PR026421; Mon, 13 Jul 2009 22:17:01 -0400 (EDT)
To: [e-mail]
Subject: WG Last Call: draft-ietf-sasl-gs2-14
From: Tom Yu <[e-mail]>
Date: Mon, 13 Jul 2009 22:17:01 -0400
Message-ID: <[e-mail]>
Lines: 16
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message commences a WG Last Call on the following Internet-Draft:

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

This Last Call will expire on 03 August 2009.  This document is
intended for the Standards Track.  Please review this document and
send technical feedback to the WG mailing list, and editorial comments
to the authors.

-- 
Tom Yu
IETF SASL WG co-chair



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68GX66T052420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 09:33:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n68GX6hb052419; Wed, 8 Jul 2009 09:33:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68GX55a052413 for <[e-mail]>; Wed, 8 Jul 2009 09:33:06 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.169] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 8 Jul 2009 17:33:03 +0100
Message-ID: <[e-mail]>
Date: Wed, 08 Jul 2009 17:31:53 +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]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
References: <[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>

Nicolas Williams wrote:

>On Wed, Jul 08, 2009 at 01:11:57PM +0100, Alexey Melnikov wrote:
>  
>
>>Some quick comments.
>>
>>In Section 3.5:
>>    
>>
>>>  If the client negotiates mechanisms then clients MUST select the
>>>  PLUS-variant if offered by the server.
>>>      
>>>
>>This make sense.
>>    
>>
>>>Otherwise, if the client does
>>>  not negotiate mechanisms then it MUST use the non-PLUS variant.
>>>      
>>>
>>This doesn't make much sense. If the client remembers what the server 
>>advertised previously, then it can just use the same mechanism.
>>But even if the client never negotiate mechanisms (e.g. if the user 
>>selected the mechanism in UI), then why should it be restricted to 
>>non-PLUS variant?
>>    
>>
>I think that text had been intended to say that the non-PLUS variant
>must be selected when the client has no idea what the server supports
>and the client isn't using CB.  But it doesn't really matter.  I'd be
>happy with removing this text.
>  
>
Alternatively I suggest correcting the text to read something like this:

    Otherwise (the client does not negotiate mechanisms),
    if the client has no prior knowledge about mechanisms supported
    by the server and wasn't explicitly configured to use a particular
    variant of the GS2 mechanism, then it MUST select
    only non-PLUS version of the GS2 mechanism.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68G0R2D049752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 09:00:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n68G0RWv049751; Wed, 8 Jul 2009 09:00: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-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 n68G0GV3049731 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 8 Jul 2009 09:00: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 n68G0GXp026018 for <[e-mail]>; Wed, 8 Jul 2009 16:00: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 n68G0FH0062902 for <[e-mail]>; Wed, 8 Jul 2009 10:00: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 n68Fo2Bn001677; Wed, 8 Jul 2009 10:50:02 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n68Fo2Aw001676; Wed, 8 Jul 2009 10:50:02 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 8 Jul 2009 10:50:02 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.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 Wed, Jul 08, 2009 at 12:22:57PM +0100, Alexey Melnikov wrote:
> Nico,
> 
> I believe I've addressed all your comments in my copy.

OK, thanks.  I'll 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 n68FugAb049413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 08:56:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n68Fugcv049412; Wed, 8 Jul 2009 08:56: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 n68FuVUf049394 for <[e-mail]>; Wed, 8 Jul 2009 08:56:41 -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 n68FuVdi027581 for <[e-mail]>; Wed, 8 Jul 2009 15:56:31 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n68FuUxO059971 for <[e-mail]>; Wed, 8 Jul 2009 09:56: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 n68FkF0q001665; Wed, 8 Jul 2009 10:46:15 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n68FkEn7001664; Wed, 8 Jul 2009 10:46:14 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 8 Jul 2009 10:46:13 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.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 Wed, Jul 08, 2009 at 01:11:57PM +0100, Alexey Melnikov wrote:
> Some quick comments.
> 
> In Section 3.5:
> 
> >   If the client negotiates mechanisms then clients MUST select the
> >   PLUS-variant if offered by the server.
> 
> This make sense.
> 
> >Otherwise, if the client does
> >   not negotiate mechanisms then it MUST use the non-PLUS variant.
> 
> This doesn't make much sense. If the client remembers what the server 
> advertised previously, then it can just use the same mechanism.
> But even if the client never negotiate mechanisms (e.g. if the user 
> selected the mechanism in UI), then why should it be restricted to 
> non-PLUS variant?

I think that text had been intended to say that the non-PLUS variant
must be selected when the client has no idea what the server supports
and the client isn't using CB.  But it doesn't really matter.  I'd be
happy with removing this text.

> In Section 5.1:
> 
> >   The application-data field MUST be set to the gs2-header concatenated
> >   with, when a gs2-cb-flag of "p" is used, the application's channel
> >   binding data (if any).
> 
> I think "(if any)" should be removed, because for "p" the channel 
> binding data is always present. I assume that a channel binding data 
> can't be the empty string.

Sure.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68E4Olr039944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 07:04:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n68E4OgD039943; Wed, 8 Jul 2009 07:04:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68E4Dgw039920 for <[e-mail]>; Wed, 8 Jul 2009 07:04:24 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.169] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 8 Jul 2009 15:04:12 +0100
Message-ID: <[e-mail]>
Date: Wed, 08 Jul 2009 15:03:12 +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: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[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           : Salted Challenge Response (SCRAM) SASL Mechanism
>	Author(s)       : A. Menon-Sen, et al.
>	Filename        : draft-ietf-sasl-scram-02.txt
>	Pages           : 33
>	Date            : 2009-07-08
>  
>
This version bringins SCRAM inline with the latest GS2 (-14). It also 
addresses editorial comments from Nico.
This should be ready for WGLC.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68E0U09039625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 07:00:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n68E0Ux1039624; Wed, 8 Jul 2009 07:00:30 -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 n68E0TY9039618 for <[e-mail]>; Wed, 8 Jul 2009 07:00:29 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id BCD1F3A6929; Wed,  8 Jul 2009 07:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-scram-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed,  8 Jul 2009 07: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           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-02.txt
	Pages           : 33
	Date            : 2009-07-08

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

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-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-scram-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 n68CCrxG031337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 05:12:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n68CCr4j031334; Wed, 8 Jul 2009 05:12:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68CCpX4031324 for <[e-mail]>; Wed, 8 Jul 2009 05:12:52 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.169] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 8 Jul 2009 13:12:50 +0100
Message-ID: <[e-mail]>
Date: Wed, 08 Jul 2009 13:11: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: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-14.txt
References: <[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>

[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           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
>	Author(s)       : S. Josefsson, N. Williams
>	Filename        : draft-ietf-sasl-gs2-14.txt
>	Pages           : 23
>	Date            : 2009-06-27
>  
>
Some quick comments.

In Section 3.5:

>    If the client negotiates mechanisms then clients MUST select the
>    PLUS-variant if offered by the server.

This make sense.

> Otherwise, if the client does
>    not negotiate mechanisms then it MUST use the non-PLUS variant.

This doesn't make much sense. If the client remembers what the server 
advertised previously, then it can just use the same mechanism.
But even if the client never negotiate mechanisms (e.g. if the user 
selected the mechanism in UI), then why should it be restricted to 
non-PLUS variant?

In Section 5.1:

>    The application-data field MUST be set to the gs2-header concatenated
>    with, when a gs2-cb-flag of "p" is used, the application's channel
>    binding data (if any).

I think "(if any)" should be removed, because for "p" the channel 
binding data is always present. I assume that a channel binding data 
can't be the empty string.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68BNqja027338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 04:23:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n68BNqPQ027337; Wed, 8 Jul 2009 04:23:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n68BNoQS027329 for <[e-mail]>; Wed, 8 Jul 2009 04:23:51 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.169] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 8 Jul 2009 12:23:49 +0100
Message-ID: <[e-mail]>
Date: Wed, 08 Jul 2009 12:22: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: Nicolas Williams <[e-mail]>
CC: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
References: <[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>

Nicolas Williams wrote:
 [...]

>My only comments are editorial, otherwise I'm happy with this
>Internet-Draft:
>
> - Clarify this sentence:
>
>  "This means that SCRAM is actually both, a GSS-API and SASL mechanism."
>
>   as follows:
>
>  "This means that this document defines both, a GSS-API mechanism and a
>   SASL mechanism."
>
>   Rationale: one must remove the GS2 header from the initial context
>   token and then add the RFC2743 initial context token header in order
>   to get SCRAM as a GSS-API mechanism, therefore the original text
>   above might be confusing to some readers.  See section 8.
>
> - Section 4, there's a typo: (20-length("SCRAM-")-lenght("-PLUS")
>   (the second 'length' is misspelled).
>
> - Section 5, "SCRAM is a text protocol where...".  Really?  I thought
>   SCRAM was a mechanism, not a protocol...  How about:
>
>   "SCRAM is a SASL mechanism whose authentication messages are
>   text-based messages containing one or more attribute-value pairs
>   separated by commas."
>
>   (That these messages are exchanged by a client and server seems
>   superfluous once one describes SCRAM as a SASL mechanism.)
>
> - Section 6:
>
>"
>   o  If the client negotiates mechanisms then client MUST select SCRAM-
>      <hash-function>-PLUS if offered by the server.  Otherwise, if the
>      client does not negotiate mechanisms then it MUST select only
>      SCRAM-<hash-function> (not suffixed with "-PLUS").
>"
>
>   s/then client/then the client/
>
>   s/MUST select SCRAM-<hash-function>-PLUS if offered by the server/
>     MUST select SCRAM-<hash-function>-PLUS if offered by the server and
>     the client wants to select SCRAM with the given hash function/
>
> - Section 6:
>
>   o  If the client supports channel binding but the server does not
>      then the client MUST ...
>
>   s/the server does not/the server does not (i.e., did not offer
>     SCRAM-<hash-function>-PLUS) then the client MUST .../
>  
>
Nico,
I believe I've addressed all your comments in my copy.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n673MWqH007485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 20:22:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n673MWap007484; Mon, 6 Jul 2009 20:22:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n673MK1B007475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 6 Jul 2009 20:22:31 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n673MIuv023575 for <[e-mail]>; Mon, 6 Jul 2009 23:22:19 -0400 (EDT)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n673MHit014344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 6 Jul 2009 23:22:18 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n673MH83029027; Mon, 6 Jul 2009 23:22:17 -0400 (EDT)
To: [e-mail]
Subject: summary of SCRAM TLS channel binding discussion
From: Tom Yu <[e-mail]>
Date: Mon, 06 Jul 2009 23:22:17 -0400
Message-ID: <[e-mail]>
Lines: 83
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Having reviewed a large quantity of mailing list traffic, I will
attempt to summarize the outcome of this discussion (which spans more
than one hundred messages).  Please let me know if I appear to have
misrepresented anything.  I intend to restart the WG Last Call on
SCRAM (and start one on GS2) this week unless the authors feel that
the current versions are not ready.

There appears to be consensus around option 1a (using Alexey's
labeling): SCRAM will use a single allowed TLS channel binding type,
which is tls-unique, deferring the ability of negotiating channel
binding types.

In addition, some participants, including Nico Williams, Simon
Josefsson, Sam Hartman, and Jeff Hutzelman, worked to come up with a
compromise proposal for GS2 and SCRAM for providing a method for a
client to declare to a server what channel binding it is using, while
not committing to any specific negotiation method for channel binding
types.  There appears to be rough consensus around this proposal.

I will note that there appears to be consensus that SCRAM (and GS2)
should move forward as quickly as reasonably possible.  While there
may continue to be disagreement about the form that the negotiation
method for channel binding types will take, there appears to be rough
consensus that the current proposal for a client to declare a channel
binding does not preclude the existence of some future method for
negotiating channel binding types.  Additionally, there appears to be
consensus to defer any decision about the details of negotiating
channel binding types so that SCRAM may proceed without additional
hindrance.

As a means of realizing the working group consensus that SCRAM proceed
as quickly as reasonably possible, I strongly recommend that until we
conclude our work on the SCRAM document, any future debate about
methods of negotiating channel binding types concentrate on whether
there are specific and concrete reasons, grounded in plausible
implementation or deployment concerns, why the compromise proposal is
harmful.

                         ====================

The original poll as posted by Alexey:

    1). SCRAM should just use a single allowed TLS channel binding and
    don't have any negotiation of other TLS channel bindings (*) (**)
    a). the default is tls-unique
    b). the default is tls-server-end-point
    2). SCRAM should just use tls-server-end-point, fallback to
    tls-unique, no negotiation of other TLS channel bindings (*)
    3). SCRAM should always use channel binding negotiation (*)
    4). SCRAM should have a default TLS channel binding with optional
    negotiation of TLS channel bindings (*)
    a). the default is tls-unique
    b). the default is
    5). I have another opinion [this is for the case when there is some
    valid choice which you think should be considered by the WG]

    Notes:
    (*) - whether such negotiation happens inside or outside of SCRAM
    (**) - channel binding negotiation can be added later on

I have assumed, as have some participants, that the missing phrase in
option 4b is "tls-server-end-point".  The following text is a very
rough and incomplete summary of some individual opinions.

Jeff Hutzelman and others strongly oppose any technique that involves
registrations of N * M composed mechanism and channel binding type
names.

Simon preferred explicit registration of specific combinations,
believing that the subset of N * M with desirable security properties
is limited.

Kurt wants to ensure that any changes to GS2 or SCRAM in the area of
channel bindings do not unreasonably constrain the design of any
future SASL mechanism.  He particularly wants to avoid strategies that
could preclude purely in-mechanism channel binding type negotiation,
or make them difficult to specify or implement.  Kurt appears to
prefer a means of negotiating channel binding type by including the
name of the channel binding type in the mechanism name.

-- 
Tom Yu
IETF SASL WG co-chair