SASL WG Status

[Kurt Zeilenga <[e-mail]>]

This is a brief summary of SASL WG work items.  Tom and I have tried  
to put names on each item.  In cases where we were not sure, a  
question mark is also by the name.  Some discussion of next steps is  
needed here and there.

-- Kurt

IETF#72 minutes - Tom - Due 8/29 (Done)
WG Charter - description revision needed - Kurt/Tom - Due 9/5
RFC 4422bis - new I-D submitted, review needed (once announced) - WG -  
Due 9/30
RFC 4422 implementation reports - need response summary - Kurt - Due  
9/30
RFC 4013bis - I-D needed - Kurt - 9/30
CRAM-MD5 - next steps needed - Kurt - Due 9/5
DIGEST-MD5 - mostly done, awaiting SCRAM
GS2 - Awaiting SCRAM issue resolution
SCRAM:
   * PBKDF2 iteration counts - Nico?
   * channel binding - Nico?
   * LDAP storage of auth info
	text needed for WG consideration - Chris? - 9/30
   * make equivalent to a GS2 mech
	text needed for WG consideration - Sam/Nico?- 9/30




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m814glQt043587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Aug 2008 21:42:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m814glNK043586; Sun, 31 Aug 2008 21:42:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m814gZY8043578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 31 Aug 2008 21:42:46 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m814gXAd051152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Mon, 1 Sep 2008 04:42:34 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: SASL WG Status
Date: Sun, 31 Aug 2008 21:42:33 -0700
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a brief summary of SASL WG work items.  Tom and I have tried  
to put names on each item.  In cases where we were not sure, a  
question mark is also by the name.  Some discussion of next steps is  
needed here and there.

-- Kurt

IETF#72 minutes - Tom - Due 8/29 (Done)
WG Charter - description revision needed - Kurt/Tom - Due 9/5
RFC 4422bis - new I-D submitted, review needed (once announced) - WG -  
Due 9/30
RFC 4422 implementation reports - need response summary - Kurt - Due  
9/30
RFC 4013bis - I-D needed - Kurt - 9/30
CRAM-MD5 - next steps needed - Kurt - Due 9/5
DIGEST-MD5 - mostly done, awaiting SCRAM
GS2 - Awaiting SCRAM issue resolution
SCRAM:
   * PBKDF2 iteration counts - Nico?
   * channel binding - Nico?
   * LDAP storage of auth info
	text needed for WG consideration - Chris? - 9/30
   * make equivalent to a GS2 mech
	text needed for WG consideration - Sam/Nico?- 9/30



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7RFvvMs002012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2008 08:57:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7RFvvUS002011; Wed, 27 Aug 2008 08:57:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7RFvkli001994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 27 Aug 2008 08:57:56 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7RFvia6038208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Wed, 27 Aug 2008 15:57:45 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Clarification regarding "I believe there is consensus within the WG" CRAM-MD5 statements
Date: Wed, 27 Aug 2008 08:57:44 -0700
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On or about Aug 11 2008, I posted a number of statements regarding my  
beliefs about WG consensus of the WG regarding a number of issues  
concerning draft-ietf-sasl-crammd5.   The intent of these statements  
was to test my beliefs in preparation for subsequently taking action  
to declare WG consensus and close discussions on these issues.

I purposely made this a two-step process [1) state belief 2) declaring  
consensus/closing discussions] since my beliefs were based, in part,  
on discussions that took place long ago and I felt it appropriate to  
provide yet another opportunity for discussion the technical issue and/ 
or to state one's own beliefs regarding WG consensus.

In the next few days I intend to take action regarding these issues.   
These actions may include, but in no way limited to, declaring  
consensus (not necessarily consistent with my previously stated  
beliefs) and closing discussions regarding the issue.

Any additional input (sent to the WG list, or directly to me) received  
before I take action will be considered in the decision to take that  
action.

-- 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 m7QJJPWU004299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 12:19:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7QJJPmv004298; Tue, 26 Aug 2008 12:19:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QJJOww004289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 26 Aug 2008 12:19:24 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7QJJM4s069473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 19:19:23 GMT (envelope-from [e-mail])
Cc: Sam Hartman <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Security
Date: Tue, 26 Aug 2008 12:19:22 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Aug 26, 2008, at 11:40 AM, Simon Josefsson wrote:

>
> Kurt Zeilenga <[e-mail]> writes:
>
>> On Aug 13, 2008, at 9:18 AM, Simon Josefsson wrote:
>>
>>> Your approach would send the message that we recommend users to  
>>> prefer
>>> PLAIN+TLS over CRAM-MD5+TLS.
>>
>> The problem as I see it is that the draft doesn't make it clear that
>> we're recommending CRAM-MD5+TLS.  The one recommendation statement
>> isn't enough.
>>
>> Most implementors and deployers and users of PLAIN understand PLAIN's
>> weaknesses without even reading RFC 4616.  Reading RFC 4616  
>> reinforces
>> what folks already understand.  But even so, RFC 4616 reiterates the
>> recommendation in the Abstract and Introduction, provides examples
>> showing use with TLS, and then reinforces its recommendations by
>> clearly stated security considerations.  RFC 4616 also places
>> requirements on IETF protocols that state PLAIN is an applicable
>> authentication mechanisms that the protocol specification MUST  
>> mandate
>> implementation of strong data security services.
>>
>> Implementors, deployers and users of CRAM-MD5 appear not to well
>> understand CRAM-MD5's weaknesses and hence are more apt to ignore the
>> recommendation, especially one buried on page 5 of the specification.
>> The CRAM-MD5 specification places no mandate on IETF protocols that
>> state CRAM-MD5 is an applicable authentication mechanism.
>
> All of the above appear to be fixable by changing the CRAM-MD5  
> document.
> Right?

Yes.  But I have a hard time assuming that the changes will actually  
happen.

> A more interesting discussion seems to be: Assuming the document
> recommends CRAM-MD5+TLS sufficiently well (similar to the wording in  
> the
> PLAIN document), would such a document be acceptable to put on the
> Standards Track and with the applicability of COMMON?

I'm personally think the I-D has other issues (such as interop) would  
are not yet adequately addressed.  I do think it's possibly that the I- 
D could be revised such to address all of its known issues, but I'm  
concerned that this might be viewed as being too disruptive.

> If that is not the WG consensus, it would be clearer to abandon the
> current CRAM-MD5 specification and produce a "Moving CRAM-MD5 to
> Historic" document.

Seems like an approach worth considering...

> However, I believe CRAM-MD5+TLS, with warnings about channel binding
> vulnerabilities, is valuable to have on the standards track until  
> there
> is other solutions that we can recommend instead (i.e., GS2+SCRAM).

> Alternatively, publish the "CRAM-MD5 to Historic" document  
> simultaneously as the GS2+SCRAM document.

I suspect the alternative is likely easier to gain consensus for....

-- 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 m7QIejLp097360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 11:40:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7QIejgl097359; Tue, 26 Aug 2008 11:40:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QIeg9n097342 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 26 Aug 2008 11:40:44 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KY3T3-0002g0-P3; Tue, 26 Aug 2008 20:40:38 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Sam Hartman <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
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:080826:[e-mail]::DXdIFiNWN/O+hyoN:1uzh
X-Hashcash: 1:22:080826:[e-mail]::Qsjw789IyIusR2Yz:8c2v
X-Hashcash: 1:22:080826:[e-mail]::txCQryirznt58KYY:3uFO
X-Hashcash: 1:22:080826:[e-mail]::FfLHbDtkxFH9oxC0:JC9H
Date: Tue, 26 Aug 2008 20:40:37 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 26 Aug 2008 11:10:09 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Aug 13, 2008, at 9:18 AM, Simon Josefsson wrote:
>
>> Your approach would send the message that we recommend users to prefer
>> PLAIN+TLS over CRAM-MD5+TLS.
>
> The problem as I see it is that the draft doesn't make it clear that
> we're recommending CRAM-MD5+TLS.  The one recommendation statement
> isn't enough.
>
> Most implementors and deployers and users of PLAIN understand PLAIN's
> weaknesses without even reading RFC 4616.  Reading RFC 4616 reinforces
> what folks already understand.  But even so, RFC 4616 reiterates the
> recommendation in the Abstract and Introduction, provides examples
> showing use with TLS, and then reinforces its recommendations by
> clearly stated security considerations.  RFC 4616 also places
> requirements on IETF protocols that state PLAIN is an applicable
> authentication mechanisms that the protocol specification MUST mandate
> implementation of strong data security services.
>
> Implementors, deployers and users of CRAM-MD5 appear not to well
> understand CRAM-MD5's weaknesses and hence are more apt to ignore the
> recommendation, especially one buried on page 5 of the specification.
> The CRAM-MD5 specification places no mandate on IETF protocols that
> state CRAM-MD5 is an applicable authentication mechanism.

All of the above appear to be fixable by changing the CRAM-MD5 document.
Right?

A more interesting discussion seems to be: Assuming the document
recommends CRAM-MD5+TLS sufficiently well (similar to the wording in the
PLAIN document), would such a document be acceptable to put on the
Standards Track and with the applicability of COMMON?

If that is not the WG consensus, it would be clearer to abandon the
current CRAM-MD5 specification and produce a "Moving CRAM-MD5 to
Historic" document.

However, I believe CRAM-MD5+TLS, with warnings about channel binding
vulnerabilities, is valuable to have on the standards track until there
is other solutions that we can recommend instead (i.e., GS2+SCRAM).

Alternatively, publish the "CRAM-MD5 to Historic" document
simultaneously as the GS2+SCRAM document.

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 m7QIAOxW092799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 11:10:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7QIAORL092798; Tue, 26 Aug 2008 11:10:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QIAL92092780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 26 Aug 2008 11:10:22 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7QIAARg060257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 18:10:11 GMT (envelope-from [e-mail])
Cc: Sam Hartman <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Security
Date: Tue, 26 Aug 2008 11:10:09 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Aug 13, 2008, at 9:18 AM, Simon Josefsson wrote:

> Your approach would send the message that we recommend users to prefer
> PLAIN+TLS over CRAM-MD5+TLS.

The problem as I see it is that the draft doesn't make it clear that  
we're recommending CRAM-MD5+TLS.  The one recommendation statement  
isn't enough.

Most implementors and deployers and users of PLAIN understand PLAIN's  
weaknesses without even reading RFC 4616.  Reading RFC 4616 reinforces  
what folks already understand.  But even so, RFC 4616 reiterates the  
recommendation in the Abstract and Introduction, provides examples  
showing use with TLS, and then reinforces its recommendations by  
clearly stated security considerations.  RFC 4616 also places  
requirements on IETF protocols that state PLAIN is an applicable  
authentication mechanisms that the protocol specification MUST mandate  
implementation of strong data security services.

Implementors, deployers and users of CRAM-MD5 appear not to well  
understand CRAM-MD5's weaknesses and hence are more apt to ignore the  
recommendation, especially one buried on page 5 of the specification.   
The CRAM-MD5 specification places no mandate on IETF protocols that  
state CRAM-MD5 is an applicable authentication mechanism.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QHE0BD087328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 10:14:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7QHE0A2087327; Tue, 26 Aug 2008 10:14:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QHDxVa087318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 26 Aug 2008 10:13:59 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7QHDt0e054624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2008 17:13:56 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
In-Reply-To: <g8555c$hba$[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Appendix B in crammd5-10, IANA #178703 (was: I-D ACTION:draft-ietf-sasl-crammd5-10.txt)
Date: Tue, 26 Aug 2008 10:13:55 -0700
References: <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g8555c$hba$[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Aug 15, 2008, at 4:59 PM, Frank Ellermann wrote:

>
> Hi, the IANA considerations in the crammd5 draft are
> apparently incomplete (= no full RFC 4422 template):

I assume this is because I-D is only asking for an update, not  
registering a new mechanism.
I concur that providing a complete registration request would be better.

However, I disagree with much of your suggested content.

>
>
> | To: [e-mail]
> | Subject: Updated Registration of SASL CRAM-MD5 mechanism.
>
> | SASL mechanism name: CRAM-MD5
> | Security considerations: See RFC XXXX
> | Published specification: RFC XXXX
> | Person & email address to contact for further information:
> |      Lyndon Nerenberg <[e-mail]>
> |      IETF SASL WG     <[e-mail]>
>
> Suggestion:
>
> | To: [e-mail]
> | Subject: Updated Registration of SASL CRAM-MD5 mechanism.
>
> | SASL mechanism name:     CRAM-MD5
> | Security considerations: RFC XXXX section 5
> | Published specification: RFC XXXX
> | Person & email address to contact for further information:
> |      Lyndon Nerenberg <[e-mail]>
> | Intended usage:          COMMON
> | Owner/Change controller: IETF
> | Note:                    Replaces RFC 2195
>
> Rationale:  The SASL list is already listed as the default
> contact address in RFC 4422 apparently assuming that this
> is a persistent institution.

RFC 4422 lists [e-mail] as a place where registrations of  
mechanisms is discussed.  RFC 4422 does not list [e-mail] as  
a "default contact address" for further information about all  
registered SASL mechanisms.  RFC 4422 listed the [e-mail]  
address under the assumption that the mailing list (as opposed to the  
WG) would persist long term.

In the past, the WG has produced some registrations which included the  
WG name/email address (e.g., PLAIN), and others that didn't (e.g.,  
ANONYMOUS).

Personally, I don't care much.  I was just noting that your rationale  
seems flawed.

> RFC 4422 actually says "owner IESG", but I strongly support
> "owner IETF", as the IESG is mostly an administrative tool
> of the IETF.  See a note about "IESG approval" in RFC 5226
> section 4.1, IMO this detail could be improved in a 4422bis.

I think we should continue to list IESG <[e-mail]> as the owner  
of all mechanism specifications produced by this WG.  This practice  
appears to be consistent with RFC 4422.   To the extent you think RFC  
4422 should be changed here, I suggest you raise your concerns when  
there is a 4422bis I-D to discuss.

> The question of the "intended use" was already discussed in
> another thread,

I concur that this question has been discussed within the WG.  That  
discussion has not yet been concluded.  So, with regard to this  
suggestion, I will simply state that the "intended usage" field in the  
registration request (and, of course, any text discussing it) should  
have a value consistent with the WG consensus regarding this question.

-- 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 m7G7wsxX014059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Aug 2008 00:58:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7G7wsCC014058; Sat, 16 Aug 2008 00:58:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7G7wpTv014048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 16 Aug 2008 00:58:53 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KUGgt-0005lU-FK for [e-mail]; Sat, 16 Aug 2008 07:59:15 +0000
Received: from 212.82.251.138 ([212.82.251.138]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 16 Aug 2008 07:59:15 +0000
Received: from nobody by 212.82.251.138 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Sat, 16 Aug 2008 07:59:15 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Sat, 16 Aug 2008 10:01:01 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 28
Message-ID: <g861cb$30v$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7r2et$50e$[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.138
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: 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:

>>> http://homes.esat.kuleuven.be/~kjongsun/papers/scn02006.pdf
>>> However there is no attack on the full HMAC-MD5 in it.
>>> HMAC-MD5 should be deprecated, but it is not yet as
>>> fatal as other uses of MD5.

Sorry, I see no "HMAC-MD5" should be deprecated in this paper,
also not for HMA-SHA1, and their NMAC-variants.

The details are beyond me, but apparently the authors found
a theoretical attack, which implies that some kind of "real"
attack should exist, however nobody found it yet. =20

Please correct me if I got this wrong. =20

>> instead of "minimal", I might instead suggest "Deprecated
>> (***)" where **** includes a statement "Uses functions
>> which should be deprecated".
=20
> That's a better label for it, thanks.

Certainly clearer, but "nobody found it yet" could be a case
of "impossible to find it".  If we are going to decree that
HMAC (and NMAC) should be *deprecated* for MD5 (and SHA-1)
we need some compelling references. =20

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7FNvQOs082240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 16:57:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7FNvQeS082239; Fri, 15 Aug 2008 16:57:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7FNvN2j082231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 15 Aug 2008 16:57:25 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KU9Au-000726-RG for [e-mail]; Fri, 15 Aug 2008 23:57:44 +0000
Received: from 212.82.251.138 ([212.82.251.138]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 15 Aug 2008 23:57:44 +0000
Received: from nobody by 212.82.251.138 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 15 Aug 2008 23:57:44 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Appendix B in crammd5-10, IANA #178703 (was: I-D ACTION:draft-ietf-sasl-crammd5-10.txt)
Date:  Sat, 16 Aug 2008 01:59:27 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 41
Message-ID: <g8555c$hba$[e-mail]>
References:  <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.138
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, the IANA considerations in the crammd5 draft are
apparently incomplete (=3D no full RFC 4422 template):

| To: [e-mail]
| Subject: Updated Registration of SASL CRAM-MD5 mechanism.

| SASL mechanism name: CRAM-MD5
| Security considerations: See RFC XXXX
| Published specification: RFC XXXX
| Person & email address to contact for further information:
|      Lyndon Nerenberg <[e-mail]>
|      IETF SASL WG     <[e-mail]>

Suggestion:

| To: [e-mail]
| Subject: Updated Registration of SASL CRAM-MD5 mechanism.

| SASL mechanism name:     CRAM-MD5
| Security considerations: RFC XXXX section 5
| Published specification: RFC XXXX
| Person & email address to contact for further information:
|      Lyndon Nerenberg <[e-mail]>
| Intended usage:          COMMON
| Owner/Change controller: IETF
| Note:                    Replaces RFC 2195

Rationale:  The SASL list is already listed as the default
contact address in RFC 4422 apparently assuming that this
is a persistent institution.

RFC 4422 actually says "owner IESG", but I strongly support
"owner IETF", as the IESG is mostly an administrative tool
of the IETF.  See a note about "IESG approval" in RFC 5226
section 4.1, IMO this detail could be improved in a 4422bis.

The question of the "intended use" was already discussed in
another thread, and IANA informed me that the IESG told them
that the best way to fix this is in a new draft.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7E9tkJm006586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 02:55:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7E9tkDR006585; Thu, 14 Aug 2008 02:55: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 m7E9tf5E006565 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 14 Aug 2008 02:55:45 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KTW8m-0005vi-1Y; Thu, 14 Aug 2008 08:16:56 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Lyndon Nerenberg <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Random data
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[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:080814:[e-mail]::bqCDAx2WrhygQ7Oh:88s0
X-Hashcash: 1:22:080814:[e-mail]::aznb3IF/PR5DCNUd:F2lq
X-Hashcash: 1:22:080814:[e-mail]::C+pZC8uSXyeEqw1B:Lpdt
X-Hashcash: 1:22:080814:[e-mail]::C3OL8Idc3VaXoWDg:LOrz
Date: Thu, 14 Aug 2008 08:16:55 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Wed, 13 Aug 2008 09:50:00 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

>> As far as I know, the best published attack on HMAC-MD5
>> is this paper:
>>
>> Jongsung Kim, Alex Biryukov, Bart Preneel, Seokhie Hong, "On the
>> Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1",
>> 2006.  http://homes.esat.kuleuven.be/~kjongsun/papers/scn02006.pdf
>>
>> However there is no attack on the full HMAC-MD5 in it.  HMAC-MD5
>> should
>> be deprecated, but it is not yet as fatal as other uses of MD5.
>
> I would argue that if HMAC-MD5 should be deprecated that the status
> should be less than Medium (which implies something better than
> "should be be deprecated").
>
> So instead of "minimal", I might instead suggest "Deprecated (***)"
> where **** includes a statement "Uses functions which should be
> deprecated".

That's a better label for it, 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 m7DNklZf093435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 16:46:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DNkloM093434; Wed, 13 Aug 2008 16:46:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DNkkpv093426 for <[e-mail]>; Wed, 13 Aug 2008 16:46:46 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 634A54286; Wed, 13 Aug 2008 19:46:39 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Future of SASLprep
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 13 Aug 2008 19:46:39 -0400
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 12 Aug 2008 09:32:51 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think another thing you should adopt from IDNABIS is the idea of
code points that fall into the maybe-yes category and a permissive
rather than exclusive strategy.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DJugLw077510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 12: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 m7DJugO6077509; Wed, 13 Aug 2008 12: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 boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DJuevL077502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 12:56:42 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7DJuFCP068168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Aug 2008 19:56:16 GMT (envelope-from [e-mail])
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Tony Finch <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Random data
Date: Wed, 13 Aug 2008 12:56:14 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7v0h6$2fb$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Aug 13, 2008, at 11:52 AM, Tony Finch wrote:

>
> On Wed, 13 Aug 2008, Frank Ellermann wrote:
>> Kurt Zeilenga wrote:
>>
>> [password specific DB]
>>> PLAIN doesn't require a mechanism specific password store.
>> [...]
>>> Unlike CRAM-MD5.
>>
>> Something is odd in the table here,
>
> Yes, the "yes" and "no" were backwards in that line of the table.
>
>> CRAM-MD5 also does not require a mechanism specific password store.
>
> It does if your existing password store contains Unix-style crypted
> passwords.

The source of this requirement is not the mechanism but the password  
store.
>
>
>> Maybe what Simon had in mind was that both require to store the
>> passwords per user on the server in some form boiling down to "as  
>> is" or
>> "plain text".
>
> You don't need to store plaintext passwords for SASL PLAIN.
>
> Tony.
> -- 
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> SOLE: WEST VEERING NORTHWEST 5 TO 7, DECREASING 4 FOR A TIME. ROUGH  
> OR VERY
> ROUGH BECOMING MODERATE OR ROUGH. SQUALLY SHOWERS. GOOD.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DJWeSq075659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 12:32:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DJWe33075658; Wed, 13 Aug 2008 12:32:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DJWcQ6075651 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 12:32:39 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KTM5B-00024D-DB for [e-mail]; Wed, 13 Aug 2008 19:32:33 +0000
Received: from 212.82.251.95 ([212.82.251.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 19:32:33 +0000
Received: from nobody by 212.82.251.95 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 19:32:33 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Security
Date:  Wed, 13 Aug 2008 21:33:16 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 27
Message-ID: <g7vcs5$f0g$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]><g7v27j$8ti$[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.95
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Leach wrote:

> Use of iterated hashes to make computation of the key
> from the password take a few hundred milliseconds really
> makes a difference -- that's what PBKDF2 does.

I recently looked into the documentation of an old tool
creating such tables.  It didn't address the question of
the cumulative effect of milliseconds, but I was very
impressed by the cumulative effects of "increase the set
of potential input characters".

The math is trivial, but I never saw the consequences of
say one GB vs. 700 GB, or one day vs. 1000 days, before. =20

The larger numbers were for some proper subset of ASCII,
the smaller numbers were for upper case ASCII letters.

I think the draft is clear wrt this attack, but we could
try to make it clearer:

 Sending a response to an attacker for a challenge chosen
 by this attacker will - for most choices of a plausible
 password - reveal this password.  The mere use of TLS
 does not remove this attack vector.

Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DJ8rXV073074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 12:08:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DJ8rYO073073; Wed, 13 Aug 2008 12:08:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DJ8ort073065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 12:08:52 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KTLiA-00017E-0i for [e-mail]; Wed, 13 Aug 2008 19:08:46 +0000
Received: from 212.82.251.95 ([212.82.251.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 19:08:46 +0000
Received: from nobody by 212.82.251.95 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 19:08:46 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Wed, 13 Aug 2008 21:09:29 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 10
Message-ID: <g7vbfi$a50$[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7v0h6$2fb$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.95
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Finch wrote:

> You don't need to store plaintext passwords for SASL PLAIN.

ACK, I missed that point.  Adding Simon's fixed table to the
draft, maybe in an informative appendix, would be Good Thing.

 Frank=20





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DIql7H071509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 11:52:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DIqlOe071508; Wed, 13 Aug 2008 11:52:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ppsw-4.csi.cam.ac.uk (ppsw-4.csi.cam.ac.uk [131.111.8.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DIqjEh071498 for <[e-mail]>; Wed, 13 Aug 2008 11:52:46 -0700 (MST) (envelope-from [e-mail])
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:36238) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1KTLSe-0004G7-FY (Exim 4.70) (return-path <[e-mail]>); Wed, 13 Aug 2008 19:52:44 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1KTLSe-0002Bn-Pk (Exim 4.67) (return-path <[e-mail]>); Wed, 13 Aug 2008 19:52:44 +0100
Date: Wed, 13 Aug 2008 19:52:44 +0100
From: Tony Finch <[e-mail]>
X-X-Sender: [e-mail]
To: Frank Ellermann <[e-mail]>
cc: [e-mail]
Subject: Re: Random data
In-Reply-To: <g7v0h6$2fb$[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7v0h6$2fb$[e-mail]>
User-Agent: Alpine 1.10 (LSU 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 13 Aug 2008, Frank Ellermann wrote:
> Kurt Zeilenga wrote:
>
>  [password specific DB]
> > PLAIN doesn't require a mechanism specific password store.
> [...]
> > Unlike CRAM-MD5.
>
> Something is odd in the table here,

Yes, the "yes" and "no" were backwards in that line of the table.

> CRAM-MD5 also does not require a mechanism specific password store.

It does if your existing password store contains Unix-style crypted
passwords.

> Maybe what Simon had in mind was that both require to store the
> passwords per user on the server in some form boiling down to "as is" or
> "plain text".

You don't need to store plaintext passwords for SASL PLAIN.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
SOLE: WEST VEERING NORTHWEST 5 TO 7, DECREASING 4 FOR A TIME. ROUGH OR VERY
ROUGH BECOMING MODERATE OR ROUGH. SQUALLY SHOWERS. GOOD.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DIeYTX070621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 11:40:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DIeYAd070620; Wed, 13 Aug 2008 11:40:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DIeXRJ070612 for <[e-mail]>; Wed, 13 Aug 2008 11:40:34 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 71F7B41EF; Wed, 13 Aug 2008 14:40:27 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Security
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7v7iu$rsr$[e-mail]>
Date: Wed, 13 Aug 2008 14:40:27 -0400
In-Reply-To: <g7v7iu$rsr$[e-mail]> (Frank Ellermann's message of "Wed, 13 Aug 2008 20:03:01 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Frank> Sam Hartman wrote:

    >> we should not recommend it.

    Frank> The draft is very clear about that, maybe even on the wrong
    Frank> side of the border to exaggeration.

    Frank> To take another example, just because RFC 862 is also known
    Frank> as STD 20 doesn't mean that starting echo servers is
    Frank> "recommended".

I think echo could be moved to historic too in the limited use
category of historic.

I think at this point we've staded our positions and additional
discussion on this point is useless.

I think you've made a case that if we chose to do so, we could publish
a new cram-md5 on the standards track.  However doing that requires WG
consensus.  Whether that consensus exists is a question first
evaluated by the chairs.  I've made my position clear: I will not be
part of that consensus.  I think you have made your position clear:
you want to be part of a consensus.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DIdd02070546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 11:39:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DIddpU070545; Wed, 13 Aug 2008 11:39:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DIdbbV070538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 11:39:38 -0700 (MST) (envelope-from [e-mail])
Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 13 Aug 2008 11:39:37 -0700
Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.1.291.1; Wed, 13 Aug 2008 11:39:36 -0700
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Wed, 13 Aug 2008 11:39:36 -0700
From: Paul Leach <[e-mail]>
To: Sam Hartman <[e-mail]>, Frank Ellermann <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Wed, 13 Aug 2008 11:39:51 -0700
Subject: RE: Security
Thread-Topic: Security
Thread-Index: Acj9cLM0cq+ZPA0CS/aJvHNJRpLVLAAAqinQ
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7v27j$8ti$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Again I agree with Sam. String-to-key functions that allow attackers to mak=
e 10s of millions of password guesses per second on a single PC are definit=
ely not where the world is at today.
Use of iterated hashes to make computation of the key from the password tak=
e a few hundred milliseconds really makes a difference -- that's what PBKDF=
2 does.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Sam Hartman
Sent: Wednesday, August 13, 2008 10:56 AM
To: Frank Ellermann
Cc: [e-mail]
Subject: Re: Security

My problem is not with HMAC, but with the lack of PBKDF2.  Note that I
am acting on my proposals by contributing to scram.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DI2MjE066810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 11:02:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DI2MuN066809; Wed, 13 Aug 2008 11:02:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DI2IPp066801 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 11:02:20 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KTKfo-0006L9-CU for [e-mail]; Wed, 13 Aug 2008 18:02:17 +0000
Received: from 212.82.251.95 ([212.82.251.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 18:02:16 +0000
Received: from nobody by 212.82.251.95 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 18:02:16 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Security
Date:  Wed, 13 Aug 2008 20:03:01 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 43
Message-ID: <g7v7iu$rsr$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]><[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.95
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman wrote:

> we should not recommend it.

The draft is very clear about that, maybe even on the
wrong side of the border to exaggeration.

To take another example, just because RFC 862 is also
known as STD 20 doesn't mean that starting echo servers
is "recommended". =20

It means "IFF you do that here is how this works since
25 years":  mature + interoperable !=3D recommended.

Similar, the POP3 standard (STD 53) doesn't imply that
folks better stay away from IMAP (not a STD).  Quite
the contrary it is a point of POP3 that there will be
no additional (=3D unnecessary) features.

Ditto RFC 3986 (URIs, STD 66) vs. 3987 (IRIs, not yet
as mature as URIs).

> If people want to update digest-md5 on the standards
> track, I will not stand in their way.  I personally
> don't think it worth doing.

<shrug />  Alexey's drafts were near to ready from my
POV, but "squeeze more features into a SASL mechanism
already suffering badly from far too many features" was
no good idea. =20

Splitting it into a "+" version with a new name was an
idea.  The current standardization situation is again
strange:  RFC 2617 and 2831 are almost identical, 2831
is slightly better (wrt i18n), the better version will
be deprecated, keeping a less capable RFC 2617 (or its
successor). =20

But I'm not going to appeal the DIGEST-MD5 decision,
actually its featurism and implementation difficulties
are the reason why I defend the far simpler CRAM-MD5.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DHtqos066333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 10:55:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DHtqj0066332; Wed, 13 Aug 2008 10:55:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DHtkGw066312 for <[e-mail]>; Wed, 13 Aug 2008 10:55:51 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5DC941EF; Wed, 13 Aug 2008 13:55:40 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Security
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7v27j$8ti$[e-mail]>
Date: Wed, 13 Aug 2008 13:55:40 -0400
In-Reply-To: <g7v27j$8ti$[e-mail]> (Frank Ellermann's message of "Wed, 13 Aug 2008 18:31:38 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Frank> Sam Hartman wrote:
 
    >> However for challenge/response mechanisms we can get mutual
    >> authentication and tie the mutual authentication to integrity
    >> protection and/or confidentiality.

    Frank> As far as DIGEST-MD5 was an attempt to offer these features
    Frank> folks here apparently decided to give up on it, because
    Frank> there was no big demand for these features, and
    Frank> interoperability was lousy.  Maybe this is a hen and egg
    Frank> problem, but whatever the DIGEST-MD5 problems might be,
    Frank> they're no bugs in CRAM-MD5.

And decided to pursue channel binding rather than security layers.
Personally I'm happy with either channel binding or security layers, but think one is required.

    >> I do believe that cram-md5's mechanisms for converting a
    >> password into a key are weaker than is current accepted
    >> security practice.

    Frank> Then propose something better than HMAC, 

My problem is not with HMAC, but with the lack of PBKDF2.  Note that I
am acting on my proposals by contributing to scram.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DHfRsw065221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 10:41:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DHfRuK065220; Wed, 13 Aug 2008 10:41:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DHfOCU065205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 10:41:25 -0700 (MST) (envelope-from [e-mail])
Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 13 Aug 2008 10:41:19 -0700
Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.1.291.1; Wed, 13 Aug 2008 10:41:17 -0700
Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Wed, 13 Aug 2008 10:41:04 -0700
From: Paul Leach <[e-mail]>
To: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>
CC: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Wed, 13 Aug 2008 10:41:18 -0700
Subject: RE: Security
Thread-Topic: Security
Thread-Index: Acj9ZIAXdEkBmGSsTcGkp9UwDRkZ8gABrbFg
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lots of snips in what's quoted below, but I agree with Sam, and add that if=
 CRADM-MD5 doesn't have channel binding capabilities, then the weaknesses h=
e cites _can not_ be fixed by using TLS. (As recent DefCon talks have shown=
 with other protocols.)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Simon Josefsson
Sent: Wednesday, August 13, 2008 9:19 AM
To: Sam Hartman
Cc: Kurt Zeilenga; Frank Ellermann; [e-mail]
Subject: Re: Security


Sam Hartman <[e-mail]> writes:

>
> However for challenge/response mechanisms we can get mutual
> authentication and tie the mutual authentication to integrity
> protection and/or confidentiality.  Since cram-md5 does not support
> these capabilities either through security layers or channel binding,
>  I do not think it should be updated on the standards track.
>
We disagree on the principal here.  Merely because there are known
vulnerabilities (which can be fixed by using TLS), that shouldn't
prevent something to go on the standards track...




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGo6aj059228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 09:50:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DGo6ap059227; Wed, 13 Aug 2008 09:50:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGo5le059216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 09:50:06 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7DGo00n053305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Aug 2008 16:50:01 GMT (envelope-from [e-mail])
Cc: Lyndon Nerenberg <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Random data
Date: Wed, 13 Aug 2008 09:50:00 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Aug 13, 2008, at 9:00 AM, Simon Josefsson wrote:

>>> Cryptographic security
>>> status                     None                Medium (***)
>>
>> Though I am certainly not an crypto expert, I would not give CRAM-MD5
>> a medium here.  I'd probably give it a Minimal, to imply that the
>> security benefit the mechanism gains by its use of crypto is minimal.
>
> Any reference?

I think we're talking about to different qualities.  Your using this  
merely to indicate the relative strength of HMAC-MD5 over possible  
alternatives.   I'm using this to reflect that the mechanism makes  
limited use of crypto and that a challedge-response system could do  
much better.  But anyways (using your intended quality).

> As far as I know, the best published attack on HMAC-MD5
> is this paper:
>
> Jongsung Kim, Alex Biryukov, Bart Preneel, Seokhie Hong, "On the
> Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1",
> 2006.  http://homes.esat.kuleuven.be/~kjongsun/papers/scn02006.pdf
>
> However there is no attack on the full HMAC-MD5 in it.  HMAC-MD5  
> should
> be deprecated, but it is not yet as fatal as other uses of MD5.

I would argue that if HMAC-MD5 should be deprecated that the status  
should be less than Medium (which implies something better than  
"should be be deprecated").

So instead of "minimal", I might instead suggest "Deprecated (***)"  
where **** includes a statement "Uses functions which should be  
deprecated".

>
>
> If I understand correctly, there is a security proof of HMAC-MD5 even
> considering MD5 is weak in:
>
> http://eprint.iacr.org/2006/043
>
> The only reason I can see to say anything else than 'High' here is  
> that
> MD5 is likely to go away from libraries eventually, and that it is
> safest to move away from HMAC-MD5 while we can.
>
> Saying that the crypto HMAC-MD5 provides is minimal appears false: its
> security does not seem to have been lowered from a practical point of
> view after the MD5 attacks.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGXoul057877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 09:33:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DGXoa5057876; Wed, 13 Aug 2008 09:33:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGXg2E057867 for <[e-mail]>; Wed, 13 Aug 2008 09:33:49 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E9DB41EF; Wed, 13 Aug 2008 12:33:37 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 13 Aug 2008 12:33:37 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Wed, 13 Aug 2008 18:18:34 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Simon> We disagree on the principal here.  Merely because there
    Simon> are known vulnerabilities (which can be fixed by using
    Simon> TLS), that shouldn't prevent something to go on the
    Simon> standards track.  If that were the metric, we wouldn't
    Simon> publish SMTP on the standards track due to spam concerns.
    Simon> You make it sound as if only perfect protocols should be on
    Simon> the standards track.

I don't think I'd characterize things that way.  I think we should put
something on the standards track when we believe it is a good instance
of whatever it does.  There should be no significant vulnerabilities
that we can fix while it's still the same thing.

I think plain meets this criteria today.  In a few years, I suspect
we'll decide that phishing concerns are more important than the
ability to support plaintext passwords over TLS.

In particular, plain is the best we can do while supporting legacy
password systems.

Cram-md5 is no longer a good instance of a challenge-response
mechanism.  The world has evolved and integrity/confidentiality
protection are important, as is mutual authentication all at one
layer.  As such, I think cram-md5 no longer meets good practice for
the design of a challenge-response mechanism, so we should not
recommend it.

Note that my arguments do not apply to digest-md5.  If people want to
update digest-md5 on the standards track, I will not stand in their
way.  I personally don't think it worth doing.


To come back to your example of SMTP, I think if we had viable
proposal for an email transport that did not have spam concerns, we
should seriously question whether SMTP should remain on the standards
track.  I'm aware of no such proposals.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGUuqb057610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 09:30:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DGUu0R057609; Wed, 13 Aug 2008 09:30:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGUrVJ057587 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 09:30:55 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KTJFL-0002RH-RR for [e-mail]; Wed, 13 Aug 2008 16:30:51 +0000
Received: from 212.82.251.95 ([212.82.251.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 16:30:51 +0000
Received: from nobody by 212.82.251.95 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 16:30:51 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Security
Date:  Wed, 13 Aug 2008 18:31:38 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 32
Message-ID: <g7v27j$8ti$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.95
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman wrote:
=20
> However for challenge/response mechanisms we can get mutual
> authentication and tie the mutual authentication to integrity
> protection and/or confidentiality.

As far as DIGEST-MD5 was an attempt to offer these features
folks here apparently decided to give up on it, because there
was no big demand for these features, and interoperability
was lousy.  Maybe this is a hen and egg problem, but whatever
the DIGEST-MD5 problems might be, they're no bugs in CRAM-MD5.

> I do believe that cram-md5's mechanisms for converting a
> password into a key are weaker than is current accepted
> security practice.

Then propose something better than HMAC, get it on standards
track, and deployed.  Removing CRAM-MD5 from standards track
won't get you there.  One algorithm I looked at (APR1) is IMO
far too odd to pass as "better".

When I proposed to look at RMX in a SCRAM-discussion the WG
apparently preferred what's now in the draft, based on HMAC.

Maybe SCRAM will be that "better" thing, but that's unrelated
to WG Charter and status questions for CRAM-MD5. =20

It's IMO very good that it is now again possible to discuss
such issues, the situation where you in essence had a veto
was unsound (actually a "bug" in RFC 2026, not in RFC 2195).

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGIjrO056324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 09:18:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DGIjta056323; Wed, 13 Aug 2008 09:18:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DGIgZA056315 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 09:18:44 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KTJ3V-0005m4-Ef; Wed, 13 Aug 2008 18:18:38 +0200
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
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:080813:[e-mail]::NcejZcfko30wATUu:0sLH
X-Hashcash: 1:22:080813:[e-mail]::tR6CQXlnV3W2Wl2S:1aOB
X-Hashcash: 1:22:080813:[e-mail]::N06Cozx3EGCtj2SJ:3fmP
X-Hashcash: 1:22:080813:[e-mail]::ExaFOqKJNXofro3+:PKCj
Date: Wed, 13 Aug 2008 18:18:34 +0200
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Wed, 13 Aug 2008 10:17:31 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman <[e-mail]> writes:

>>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:
>
>     Simon> Sure, but if CRAM-MD5 is used with TLS, the initial
>     Simon> statement above is misleading: there is nothing in the
>     Simon> security considerations of CRAM-MD5 that explains how
>     Simon> CRAM-MD5 under TLS fails to provide adequate protection.
>
>     >> It is my belief that WG consensus is that the current text is
>     >> adequate in both of these areas.  I encourage anyone who thinks
>     >> the current text can be approved upon offer alternative text
>     >> for the WG to consider.
>
>     Simon> I suspect people read different things into the first
>     Simon> statement here.  I suggest to change it to:
>
>     Simon>   CRAM-MD5 used without TLS is no longer considered to
>     Simon> provide adequate protection.
>
> I don't object to this change.
> I do object to cram-md5 on the standards track.
>
> Kurt commented that recommendations for cram-md5 should be the same
> for plain.  I disagree because since cram-md5 is a challenge/response
> mechanism we can do better than plain.  Plain is the best we can do in
> cases where you need to send a password to the server.
>
> However for challenge/response mechanisms we can get mutual
> authentication and tie the mutual authentication to integrity
> protection and/or confidentiality.  Since cram-md5 does not support
> these capabilities either through security layers or channel binding,
>  I do not think it should be updated on the standards track.
>
> Also, I do believe that cram-md5's mechanisms for converting a
> password into a key are weaker than is current accepted security
> practice.

We disagree on the principal here.  Merely because there are known
vulnerabilities (which can be fixed by using TLS), that shouldn't
prevent something to go on the standards track.  If that were the
metric, we wouldn't publish SMTP on the standards track due to spam
concerns.  You make it sound as if only perfect protocols should be on
the standards track.

Your approach would send the message that we recommend users to prefer
PLAIN+TLS over CRAM-MD5+TLS.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DG22Fo054378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 09:02:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DG22DI054377; Wed, 13 Aug 2008 09:02:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DG1x4v054362 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 09:02:01 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KTInK-00017u-6Q for [e-mail]; Wed, 13 Aug 2008 16:01:54 +0000
Received: from 212.82.251.95 ([212.82.251.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 16:01:54 +0000
Received: from nobody by 212.82.251.95 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 16:01:54 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Wed, 13 Aug 2008 18:02:37 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 37
Message-ID: <g7v0h6$2fb$[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.95
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

 [password specific DB]
> PLAIN doesn't require a mechanism specific password store.
[...]
> Unlike CRAM-MD5.

Something is odd in the table here, CRAM-MD5 also does not
require a mechanism specific password store. =20

Maybe what Simon had in mind was that both require to store
the passwords per user on the server in some form boiling
down to "as is" or "plain text".  =20

Of course the server needs to know how SASLprep works for
comparisons of canonical (as defined by SASLprep) strings.

>> Cryptographic security
>> status                     None           Medium (***)
=20
> I am certainly not an crypto expert, I would not give
> CRAM-MD5 a medium here.  I'd probably give it a Minimal

I think "minimal" would be something like SHA-1, where
you could buy a "reverse table" for almost any keyboard
input up to length 14 or similar.

So far HMAC doesn't have this problem.  That's the reason
why I forwarded a recent statement by Paul Hoffman about
HMAC to this list some weeks ago.

Especially wannabe-improvements of HMAC-MD5 to HMAC-SHA1
appear to be snake oil, both do their job.  The (***) in
Simon's table and Paul hopefully qualify as experts for
the purpose of judging HMAC security.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DG0Pta054206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 09:00:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DG0PHY054205; Wed, 13 Aug 2008 09:00:25 -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 m7DG0GvV054190 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 09:00:23 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KTIlc-0005lf-Ht; Wed, 13 Aug 2008 18:00:11 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Lyndon Nerenberg <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Random data
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080813:[e-mail]::c+6IkjxXXN9SvaC6:2sMn
X-Hashcash: 1:22:080813:[e-mail]::l1oAtdpwKMqEo1Mp:3yr1
X-Hashcash: 1:22:080813:[e-mail]::DvYz3y1q4oWOvqHt:9M8S
X-Hashcash: 1:22:080813:[e-mail]::cIBXPW4ya1robqI4:HNDF
Date: Wed, 13 Aug 2008 18:00:04 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Wed, 13 Aug 2008 07:55:04 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

>>                        PLAIN               CRAM-MD5
>>
>> Support for
>> Authorization             Yes                  No
>> Identity
>
> Supports Mutual Authentication	No No

I'd add (*) to these as well, since TLS support mutual auth.

> Transfers identities in clear text	Yes (*)	Yes (*)

Good addition.

>> Transfers
>> Passwords
>> in Clear Text             Yes (*)              No
>>
>> Compatible with
>> hashed password           Yes                  No
>> databases, such
>> as Unix
>> /etc/shadow (**)
>>
>> Requires a
>> mechanism-                Yes                  No
>> specific
>> password database (**)
>
> Your answers to this seem reversed.
>
> PLAIN doesn't require a mechanism specific password store.  Given the
> server has the presented password, the server can verify it against
> any password store, regardless of the algorithms used in that
> storage.  Unlike CRAM-MD5.

Exactly right, I got them reversed.

>> Supports a
>> Channel Binding            No                  No
>>
>> Cryptographic security
>> status                     None                Medium (***)
>
> Though I am certainly not an crypto expert, I would not give CRAM-MD5
> a medium here.  I'd probably give it a Minimal, to imply that the
> security benefit the mechanism gains by its use of crypto is minimal.

Any reference?  As far as I know, the best published attack on HMAC-MD5
is this paper:

Jongsung Kim, Alex Biryukov, Bart Preneel, Seokhie Hong, "On the
Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1",
2006.  http://homes.esat.kuleuven.be/~kjongsun/papers/scn02006.pdf

However there is no attack on the full HMAC-MD5 in it.  HMAC-MD5 should
be deprecated, but it is not yet as fatal as other uses of MD5.

If I understand correctly, there is a security proof of HMAC-MD5 even
considering MD5 is weak in:

http://eprint.iacr.org/2006/043

The only reason I can see to say anything else than 'High' here is that
MD5 is likely to go away from libraries eventually, and that it is
safest to move away from HMAC-MD5 while we can.

Saying that the crypto HMAC-MD5 provides is minimal appears false: its
security does not seem to have been lowered from a practical point of
view after the MD5 attacks.

>> Support for non-ASCII
>> identities (SASLPrep       Yes                 No (?)
>> or UTF-8)
>>
>> ...
>>
>> (*) PLAIN solves the security problem by being used under TLS.
>>
>>
>> (**) This is a consequence of the previous item, but explained from a
>> different point of view which often comes up in deployment.
>>
>> (***) There are no published attack against HMAC-MD5 even though the
>> underlying MD5 function has been attacked.  There are analysis that
>> suggests HMAC can be used securely even with moderately broken hash
>> functions. [Reference to Krawczyk's paper]
>
> There is still concerns about dictionary attacks.   Of course, this
> isn't much of an issue when TLS is used.

Right.

/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 m7DFQWqw051789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 08:26:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DFQWZR051788; Wed, 13 Aug 2008 08:26:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DFQNZ4051765 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 08:26:31 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KTIEs-0007zp-64 for [e-mail]; Wed, 13 Aug 2008 15:26:18 +0000
Received: from 212.82.251.95 ([212.82.251.95]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 15:26:18 +0000
Received: from nobody by 212.82.251.95 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Wed, 13 Aug 2008 15:26:18 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Wed, 13 Aug 2008 17:27:00 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 26
Message-ID: <g7uued$qj5$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7r2et$50e$[e-mail]><[e-mail]><g7rl7f$kdl$[e-mail]><[e-mail]><g7ru9t$hrf$[e-mail]> <[e-mail]> <g7sqm1$r2a$[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.95
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lyndon Nerenberg wrote:

>> often the LHS is derived from the time (easily guessed) and the
>> process id (generally sequentially allocated, and easily brute
>> forced due to the restricted range).
=20
> Sorry folks, brain in neutral. The above isn't relevant to CRAM.
> That crept in from another project I worked on.

Wait, I think it *IS* relevant.  Where the opposition can predict
a plausible challenge it won't help with security.  However the
"new" MUST NOT asks clients to never look at the details of the
challenge, therefore this point would be moot.

In another article I proposed a SHOULD that might better express
"this is not about strict msg-id syntax, but it could be related
 to security" than the MUST NOT.

>> The discussion pre-dated the documents adoption by the WG, but
>> I'm reasonably certain it took place on the WG mailing list.
>> If you're adventurous, check the list archives.

My obsession with Message-IDs (worldwide unique forever, no hash
or random number is good enough) doesn't go that far today... :-)

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DEtC54048773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 07:55:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DEtCWP048772; Wed, 13 Aug 2008 07:55:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DEtAGP048765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 07:55:11 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7DEt4ZD043146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Aug 2008 14:55:05 GMT (envelope-from [e-mail])
Cc: Lyndon Nerenberg <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Random data
Date: Wed, 13 Aug 2008 07:55:04 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Aug 12, 2008, at 2:34 AM, Simon Josefsson wrote:

>
> Lyndon Nerenberg <[e-mail]> writes:
>
>>> Depends on which traits one thinks are desirable.   In general, I
>>> would say that CRAM-MD5 offers slightly better security than PLAIN,
>>> while PLAIN offers better ability to support external/legacy
>>> password stores, proxy-authz, etc.
>>
>> Where is the peer reviewed analysis of CRAM-MD5 vs. PLAIN that
>> everyone alludes to? A simple reference to it in son-of-2195 would
>> solve this argument.
>
> I'm not aware of any existing good analysis of C vs P, but a  
> comparison
> can be made in a table.  Here is a starting point.  Questions of the
> applicability of PLAIN vs CRAM-MD5 often comes up in deployment
> discussions, so I agree that adding it to 2195bis would be a good  
> thing.
>
> This straw-man needs to be expanded and reviewed carefully though.
>
>
>                        PLAIN               CRAM-MD5
>
> Support for
> Authorization             Yes                  No
> Identity

Supports Mutual Authentication	No No

Transfers identities in clear text	Yes (*)	Yes (*)
>
>
> Transfers
> Passwords
> in Clear Text             Yes (*)              No
>
> Compatible with
> hashed password           Yes                  No
> databases, such
> as Unix
> /etc/shadow (**)
>
> Requires a
> mechanism-                Yes                  No
> specific
> password database (**)

Your answers to this seem reversed.

PLAIN doesn't require a mechanism specific password store.  Given the  
server has the presented password, the server can verify it against  
any password store, regardless of the algorithms used in that  
storage.  Unlike CRAM-MD5.

>
>
> Supports a
> Channel Binding            No                  No
>
> Cryptographic security
> status                     None                Medium (***)

Though I am certainly not an crypto expert, I would not give CRAM-MD5  
a medium here.  I'd probably give it a Minimal, to imply that the  
security benefit the mechanism gains by its use of crypto is minimal.

>
>
> Support for non-ASCII
> identities (SASLPrep       Yes                 No (?)
> or UTF-8)
>
> ...
>
> (*) PLAIN solves the security problem by being used under TLS.
>
>
> (**) This is a consequence of the previous item, but explained from a
> different point of view which often comes up in deployment.
>
> (***) There are no published attack against HMAC-MD5 even though the
> underlying MD5 function has been attacked.  There are analysis that
> suggests HMAC can be used securely even with moderately broken hash
> functions. [Reference to Krawczyk's paper]

There is still concerns about dictionary attacks.   Of course, this  
isn't much of an issue when TLS is used.

>
>
> /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 m7DEHdit045608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 07:17:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7DEHdUv045607; Wed, 13 Aug 2008 07:17:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7DEHbDc045596 for <[e-mail]>; Wed, 13 Aug 2008 07:17:38 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CA8DF41EF; Wed, 13 Aug 2008 10:17:31 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 13 Aug 2008 10:17:31 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Tue, 12 Aug 2008 19:31:49 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Simon> Sure, but if CRAM-MD5 is used with TLS, the initial
    Simon> statement above is misleading: there is nothing in the
    Simon> security considerations of CRAM-MD5 that explains how
    Simon> CRAM-MD5 under TLS fails to provide adequate protection.

    >> It is my belief that WG consensus is that the current text is
    >> adequate in both of these areas.  I encourage anyone who thinks
    >> the current text can be approved upon offer alternative text
    >> for the WG to consider.

    Simon> I suspect people read different things into the first
    Simon> statement here.  I suggest to change it to:

    Simon>   CRAM-MD5 used without TLS is no longer considered to
    Simon> provide adequate protection.

I don't object to this change.
I do object to cram-md5 on the standards track.

Kurt commented that recommendations for cram-md5 should be the same
for plain.  I disagree because since cram-md5 is a challenge/response
mechanism we can do better than plain.  Plain is the best we can do in
cases where you need to send a password to the server.

However for challenge/response mechanisms we can get mutual
authentication and tie the mutual authentication to integrity
protection and/or confidentiality.  Since cram-md5 does not support
these capabilities either through security layers or channel binding,
 I do not think it should be updated on the standards track.

Also, I do believe that cram-md5's mechanisms for converting a
password into a key are weaker than is current accepted security
practice.

--Sam



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D9Vfjj021169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 02:31:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7D9VfZc021168; Wed, 13 Aug 2008 02:31:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D9VcNM021159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 13 Aug 2008 02:31:40 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KTChc-0005iI-Jm; Wed, 13 Aug 2008 11:31:36 +0200
From: Simon Josefsson <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
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:080813:[e-mail]::CCHeN4I2EvFIcAgh:PHZ
X-Hashcash: 1:22:080813:[e-mail]::8TxVLr3d3w6/tIdx:1j6J
X-Hashcash: 1:22:080813:[e-mail]::5bY4VS1nFkxAbcOH:3/lW
X-Hashcash: 1:22:080813:[e-mail]::sZOpYc2YYHyvEsXG:5tHj
Date: Wed, 13 Aug 2008 11:31:35 +0200
In-Reply-To: <[e-mail]> (Hallvard B. Furuseth's message of "Wed, 13 Aug 2008 07:12:09 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> Simon Josefsson writes:
>> Kurt Zeilenga <[e-mail]> writes:
>>>> SHOULD has worked fine for PLAIN, so I disagree.
>>>
>>> It works fine because of PLAIN's design.  The party, the server, is
>>> preparing both the presented and stored strings.   In CRAM-MD5, two
>>> parties need to agree on the preparation on what preparation to use
>>> for things to work properly.
>>
>> Ah, I understand your objection now.
>>
>> Given that RFC 2195 appears to be ASCII only, I don't see a problem with
>> extending it to UTF-8 in a revised version and mandate that using a
>> SHOULD or MUST though.
>
> It doesn't say the password is ASCII, only that the digest being
> sent is.  Authentication breaks if the password is UTF-8, one
> protocol peer SASLpreps it, and the other does not.
>
> OTOH it also breaks if the password is Latin-1, one peer translates to
> UTF-8, and the other does not.  "MUST use UTF8/SASLprep" in practice
> implies "client and whoever creates server secret MUST know which
> character encoding is in use, so it can translate to UTF-8 if needed".
> Simple solutions to that would be to reject 8-bit input or make it the
> user's problem and expect UTF-8 input, of course.

True.  However, I think it is reasonable to assume that RFC 2195
intended for passwords to be ASCII only.  We can fix this lack of detail
with new text that says MUST UTF-8+SASLprep before hashing in 2195bis.
This is a problem that can be fixed when revising a standard, it doesn't
necessarily mean the standard is broken without any chance of rescuing
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 m7D8oOGA018051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 01:50:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7D8oOes018050; Wed, 13 Aug 2008 01:50:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (gandalf.orthanc.ca [216.40.124.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D8oMBY018044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 13 Aug 2008 01:50:23 -0700 (MST) (envelope-from [e-mail])
Received: from [74.210.65.47] ([74.210.65.47]) (authenticated bits=0) by orthanc.ca (8.14.2/8.14.2) with ESMTP id m7D8oBbT017661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 01:50:13 -0700 (PDT) (envelope-from [e-mail])
Date: Wed, 13 Aug 2008 01:50:06 -0700 (PDT)
From: Lyndon Nerenberg <[e-mail]>
X-X-Sender: [e-mail]
To: Frank Ellermann <[e-mail]>
cc: [e-mail]
Subject: Re: Random data
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><g7r2et$50e$[e-mail]><[e-mail]><g7rl7f$kdl$[e-mail]><[e-mail]><g7ru9t$hrf$[e-mail]> <[e-mail]> <g7sqm1$r2a$[e-mail]> <[e-mail]>
Organization: The Frobozz Magic Homing Pigeon Company
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Status: No, score=0.1 required=5.0 tests=RDNS_NONE autolearn=no version=3.2.3
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on orthanc.ca
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 1) The format is highly predictable. In particular, the RHS of the message id 
> is often easily derived from the host's IP address. And often the LHS is 
> derived from the time (easily guessed) and the process id (generally 
> sequentially allocated, and easily brute forced due to the restricted range).

Sorry folks, brain in neutral. The above isn't relevant to CRAM. That 
crept in from another project I worked on.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D5CHhu003951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 22:12:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7D5CH72003949; Tue, 12 Aug 2008 22:12:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D5CDQf003937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 22:12:15 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1KT8eX-0005M2-QM; Wed, 13 Aug 2008 07:12:09 +0200
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx1.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1KT8eX-0002TE-KR; Wed, 13 Aug 2008 07:12:09 +0200
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1KT8eX-0003M7-2T; Wed, 13 Aug 2008 07:12:09 +0200
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 13 Aug 2008 07:12:09 +0200
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: BBAE52252E9F00203FE8BFD24C666E65292E26B2
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 961 max/h 8 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> Kurt Zeilenga <[e-mail]> writes:
>>> SHOULD has worked fine for PLAIN, so I disagree.
>>
>> It works fine because of PLAIN's design.  The party, the server, is
>> preparing both the presented and stored strings.   In CRAM-MD5, two
>> parties need to agree on the preparation on what preparation to use
>> for things to work properly.
>
> Ah, I understand your objection now.
>
> Given that RFC 2195 appears to be ASCII only, I don't see a problem with
> extending it to UTF-8 in a revised version and mandate that using a
> SHOULD or MUST though.

It doesn't say the password is ASCII, only that the digest being
sent is.  Authentication breaks if the password is UTF-8, one
protocol peer SASLpreps it, and the other does not.

OTOH it also breaks if the password is Latin-1, one peer translates to
UTF-8, and the other does not.  "MUST use UTF8/SASLprep" in practice
implies "client and whoever creates server secret MUST know which
character encoding is in use, so it can translate to UTF-8 if needed".
Simple solutions to that would be to reject 8-bit input or make it the
user's problem and expect UTF-8 input, of course.

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D2EXkk093921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 19:14:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7D2EXwe093920; Tue, 12 Aug 2008 19:14:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (gandalf.orthanc.ca [216.40.124.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D2EWjf093912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 12 Aug 2008 19:14:32 -0700 (MST) (envelope-from [e-mail])
Received: from peregrin.orthanc.ca (peregrin.orthanc.ca [216.40.124.67]) by orthanc.ca (8.14.2/8.14.2) with ESMTP id m7D2EU8a015795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 19:14:30 -0700 (PDT) (envelope-from [e-mail])
Date: Tue, 12 Aug 2008 19:14:30 -0700 (PDT)
From: Lyndon Nerenberg <[e-mail]>
To: Frank Ellermann <[e-mail]>
cc: [e-mail]
Subject: Re: Random data
In-Reply-To: <g7sqm1$r2a$[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><g7r2et$50e$[e-mail]><[e-mail]><g7rl7f$kdl$[e-mail]><[e-mail]><g7ru9t$hrf$[e-mail]> <[e-mail]> <g7sqm1$r2a$[e-mail]>
Organization: The Frobozz Magic Homing Pigeon Company
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I'm also curious, it was in all ID.ietf-sasl-crammd5
> back to 2003, long before I started to read this list.
>
> It was introduced in ID.nerenberg-sasl-crammd5-01:

The original format of the challenge as a message-id was to encourage 
uniqueness. But the message-id format suffers from two serious flaws when 
used as a challenge:

1) The format is highly predictable. In particular, the RHS of the message 
id is often easily derived from the host's IP address. And often the LHS 
is derived from the time (easily guessed) and the process id (generally 
sequentially allocated, and easily brute forced due to the restricted 
range).

2) The character set of the message-id is very restricted, reducing 
the search space for brute force attacks.

Because of this it was decided to relax the restrictions on the syntax of 
the challenge to encourage the generation of more random and less 
predictable challenges. The current syntax does this while preserving 
backwards compatibility with older CRAM implementations (based on a 
minimal message-id of 'x@y').

The discussion pre-dated the documents adoption by the WG, but I'm 
reasonably certain it took place on the WG mailing list. If you're 
adventurous, check the list archives.

--lyndon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7D0gHms085772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 17:42:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7D0gHDL085771; Tue, 12 Aug 2008 17:42:17 -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 m7D0gENA085762 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 17:42:16 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KT4RG-0005Ro-DZ; Wed, 13 Aug 2008 02:42:10 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
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:080813:[e-mail]::vDfISDnnyigk335z:7OOt
X-Hashcash: 1:22:080813:[e-mail]::2KnHJPH+uTb7D4uK:GjEo
X-Hashcash: 1:22:080813:[e-mail]::A/aVk8jJCYjW7eSS:CP5D
Date: Wed, 13 Aug 2008 02:42:09 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 12 Aug 2008 11:31:33 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

>>>> None of the arguments made in the
>>>> document would still stand against that construct (I think).  What
>>>> is
>>>> puzzling is that the document already appear to strongly suggest use
>>>> of
>>>> TLS and UTF-8 and SASLprep, so I think we have already solved the
>>>> security and interoperability problem inherent in the old CRAM-MD5
>>>> specification.
>>>
>>> I don't believe the SHOULDs are adequate to ensure independently
>>> developed interoperability.
>>
>> SHOULD has worked fine for PLAIN, so I disagree.
>
> It works fine because of PLAIN's design.  The party, the server, is
> preparing both the presented and stored strings.   In CRAM-MD5, two
> parties need to agree on the preparation on what preparation to use
> for things to work properly.

Ah, I understand your objection now.

Given that RFC 2195 appears to be ASCII only, I don't see a problem with
extending it to UTF-8 in a revised version and mandate that using a
SHOULD or MUST though.  If some client/server uses some other mechanism
to send non-ASCII, they weren't following the RFC 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 m7CNoxAi082391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 16:50:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CNoxqD082390; Tue, 12 Aug 2008 16:50:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CNouFO082377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 16:50:58 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KT3dd-0004XT-UU for [e-mail]; Tue, 12 Aug 2008 23:50:53 +0000
Received: from 212.82.251.8 ([212.82.251.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 23:50:53 +0000
Received: from nobody by 212.82.251.8 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 23:50:53 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Security
Date:  Wed, 13 Aug 2008 01:51:41 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 58
Message-ID: <g7t7kl$29s$[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7spon$np8$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.8
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> In this case, the requirement applies to protocol specifications,
> not implementations.  It's unnecessary to say SHOULD instead of
> MUST in this case, because doing so is not going to have any effect
> on existing published protocols, but may have the wrong effect on
> new protocols.

Makes sense.  OTOH you can't have a "MUST TLS" for ESMTPA, because
the definition of ESMTPA (as opposed to ESMTPSA) is "no TLS". =20

The ESMTPA classification is no "protocol", but CRAM-MD5 is.  And
CRAM-MD5 is *the* most popular instance of this class in practice.

A SHOULD with enumerated "good excuses" could cover this situation.
Or a MUST with enumerated exceptions (at most five exceptions).

> Incidentally, my recollection is that this is exactly the sort
> of situation that arose with making CRAM-MD5 "limited use".

Based on Simon's PLAIN vs. CRAM-MD5 comparison table, and still
confident that one i18n "question mark" can be resolved. e.g. as
proposed by Kurt, this "limited use" misses far too many points.

I'd prefer CRAM-MD5 over TLS instead of PLAIN over TLS.  And in
legacy scenarios I prefer CRAM-MD5 over USER:PASS, DIGEST-MD5,
and APOP.

Admittedly "at most five exceptions" would be limited, but does
not cover CRAM-MD5 over TLS.  If you look at the SASL registry
you see that DIGEST-MD5 is listed as "common", ditto OTP.  There
is no plausible reason for this difference.

> it was felt that the method should be avoided in new protocols
> in favor of whatever new thing we end up with

Well, you certainly got the message that I consider it as FUD,
like some statements in DIGEST-MD5 how much better this is in
comparison with CRAM-MD5.  Folks saying so in blogs, or on a
list, outside of RFCs and IANA registries, is okay.  But in an
RFC and IANA registries I prefer technically justified facts.

Clearly DIGEST-MD5 does have features not offered by CRAM-MD5.
Clearly some of them aren't used or have bad interoperability
issues (the MD5sess mess).  Ignoring all that, there just is
no cnonce in CRAM-MD5, and no rspauth.  OTOH it is simple and
easy to implement, let implementors pick what they really need.

> it means "we don't think new uses of this are a good idea"

But that's a highly controversial statement.  From your POV it
is correct, from my POV it is still "when are we ready to get
rid of USER:PASS and APOP ?"  My enthusiasm for advanced stuff
that I've never implemented is also limited, especially if it
claims to offer "security" or "privacy" as defined and sold by
[insert some company you don't like].

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CMcYXR077513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 15:38:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CMcXWw077512; Tue, 12 Aug 2008 15:38:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CMcVAR077504 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 15:38:33 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KT2Va-0001fj-6Z for [e-mail]; Tue, 12 Aug 2008 22:38:30 +0000
Received: from 212.82.251.8 ([212.82.251.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 22:38:30 +0000
Received: from nobody by 212.82.251.8 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 22:38:30 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Wed, 13 Aug 2008 00:39:16 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 23
Message-ID: <g7t3cs$n7m$[e-mail]>
References:  <[e-mail]>            <[e-mail]>            <[e-mail]>            <g7r2et$50e$[e-mail]>            <[e-mail]>            <g7rl7f$kdl$[e-mail]>            <[e-mail]>            <g7ru9t$hrf$[e-mail]>            <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.8
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> If I recall correctly, there was concern that some implementations =20
> might verify that string adheres to requirements that might placed =20
> upon msg-id strings in other situations.   The desire was to say that  =

> string has no semantical value.  Maybe there is a better way to say =20
> that...

How abot this:

 The challenge SHOULD have the form "<" id-left "@" id-right ">" as
 specified for a Message-ID in [2822upd].

Really [2822upd], not RFC 2822, not RFC.usefor-usefor, not RFC 822.

I'm very sure about this.  The "SHOULD" clearly indicates "or else"
for implementors with funny ideas about checking the *syntax* for
the purposes of CRAM-MD5.  But it would allow for limited "I expect
a certain right hand side" use cases.  It would also allow for "the
same challenge more than once is broken" processing.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CMQgmx076868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 15:26:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CMQg4e076867; Tue, 12 Aug 2008 15:26:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CMQYA1076852 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 15:26:41 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KT2K2-00017w-Ej for [e-mail]; Tue, 12 Aug 2008 22:26:34 +0000
Received: from 212.82.251.8 ([212.82.251.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 22:26:34 +0000
Received: from nobody by 212.82.251.8 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 22:26:34 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Security
Date:  Wed, 13 Aug 2008 00:27:21 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 56
Message-ID: <g7t2mh$l9f$[e-mail]>
References:  <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <g7spon$np8$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.8
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

>> Normally we say "SHOULD" when we mean "old stuff
>> has a good excuse, its old".
=20
> There are many reasons to use SHOULD.

Sure, "old" is just one reason commonly accepted as=20
"good excuse" without talking about it, because a
protocol or programs written before the SHOULD was
introduced typically could not foresee this.

For other reasons updated specifications with a new
SHOULD ideally mention what might be good excuses,
otherwise folks could claim that "because I say so"
is good enough to violate a SHOULD.

 [i18n]=20
> With PLAIN, the client lack of knowledge doesn't
> matter.  It simply provides the UTF-8 encoded
> Unicode password.  The server can sort it out.

Okay, got it, when say SASLprep is used this has
to be done on the side of the client for CRAM-MD5
passwords.  For PLAIN passwords the server can do
it or something else, as long as the client sends
UTF-8 (maybe limited to Unocode 3.2).

Apparently the client "MUST NOT" use SASLprep for=20
PLAIN, that could confuse "something else" on the
server side.  Is that correct ?

SASLprep(x) =3D SASLprep( SASLprep(x)) would help
if both sides try the same preparation for PLAIN.

So we need a MUST for CRAM-MD5 and UTF8-non-ascii
passwords on the side of the client. =20

>     Except where the client and server have an a
> priori agreement to utilize a different character
> set, encoding, and/or preparation, the password
> MUST be represented using Unicode, prepared using
> SASLprep, and encoded as UTF-8 prior to input
> to the cryptographic functions.

+1  A different charset is not necessarily an issue,
when it is transformed to SASLprepped UTF-8 in the
preparation step.  That's remotely the same idea as
for IRIs in legacy charsets.

A legacy charset could be even an advantage, almost
all of them are covered by Unicode 3.2, as required
by SASLprep.

 Frank




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CKlll5070053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 13:47:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CKllXv070052; Tue, 12 Aug 2008 13:47:47 -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 m7CKlkm5070046 for <[e-mail]>; Tue, 12 Aug 2008 13:47:46 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 21:47:45 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: "Frank Ellermann" <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Tom Yu <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Random data
Date: Tue, 12 Aug 2008 13:47:42 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <g7rl7f$kdl$[e-mail]> <[e-mail]> <g7ru9t$hrf$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.926)
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 12 Aug 2008, at 8:21 AM, Tom Yu wrote:

>
> "Frank Ellermann" <[e-mail]> writes:
>
>> Tom Yu wrote:
>>
>>>> The right hand side of a challenge in "Message-ID format"
>>>> can be twisted into what I expect by an attacker, it's no
>>>> security feature.
>>
>>> Might this have been an aborted attempt at specifying how
>>> to use the challenge to transmit additional information to
>>> a server, such as channel binding information?  Or am I
>>> thinking of DIGEST?
>>
>> I'd guess that RFC 2195 uses the format of a Message-ID for
>> a challenge, because that's what APOP also uses, and a known
>> (for mail and news related protocols) concept.
>
> I meant that the introduction in draft-ietf-sasl-crammd5 of a new
> requirement that an implementation not interpret the "string that
> RFC2195 required to look like a RFC822 msg-id" might have been an
> aborted attempt to provide a "covert channel" for signaling the use of
> a channel binding.
>
> Alternatively, the new requirement that the client not interpret the
> challenge string might be an effort to improve interoperability with
> servers that do not send challenge strings that strictly conform to
> the syntax of RFC822 or RFC2822 msg-id strings.
>
> Authors or others, please elaborate if you recall the history of this
> change.
>

If I recall correctly, there was concern that some implementations  
might verify that string adheres to requirements that might placed  
upon msg-id strings in other situations.   The desire was to say that  
string has no semantical value.  Maybe there is a better way to say  
that...

-- 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 m7CKiXm9069855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 13:44:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CKiXKa069854; Tue, 12 Aug 2008 13:44:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CKiPqM069833 for <[e-mail]>; Tue, 12 Aug 2008 13:44:31 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 21:44:23 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
In-Reply-To: <g7spon$np8$[e-mail]>
Subject: Re: Security
Date: Tue, 12 Aug 2008 13:44:21 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7spon$np8$[e-mail]>
X-Mailer: Apple Mail (2.926)
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 12 Aug 2008, at 12:54 PM, Frank Ellermann wrote:

>
> Kurt Zeilenga wrote:
>
>  [TLS]
>>> That places restrictions on specifications, not implementations,
>>> which is somewhat weird, but CRAM-MD5 could do the same.  That
>>> is what I propose to do.
>
>> I personally think such a change would be good.   I feel that TLS
>> recommendations to protect CRAM-MD5 ought to be the same as those
>> we made for the TLS protection of PLAIN.
>
> Could work.  What about existing protocols, has this to be limited
> to future specifications ?

The RFC 4616 requirement upon technical specifications applies  
regardless of whether that technical specification details a new or  
existing protocol.   The requirements simply means that when one  
revises a technical specification then need to address an additional  
concern.

> Normally we say "SHOULD" when we mean
> "old stuff has a good excuse, its old".

There are many reasons to use SHOULD.

> IIRC there are a two old
> protocols with a mandatory CRAM-MD5, one of them (on demand relay)
> won't be updated anytime soon, if ever.

One might view newer requirements upon technical specification as a  
reason to update older specifications...
>
>
>  [i18n]
>>> SHOULD has worked fine for PLAIN, so I disagree.
>>
>> It works fine because of PLAIN's design.  The party, the server, is
>> preparing both the presented and stored strings.   In CRAM-MD5, two
>> parties need to agree on the preparation on what preparation to use
>> for things to work properly.
>
> I don't get this point.  A new user creating an account picks a
> free userid, and a password.  The details can vary, one way is
> online in a Web form.  If the server can note these credentials
> for PLAIN, it can also note it for CRAM-MD5 or other mechanisms,
> in any required format(s), even the somewhat odd "APR1" format.

The point is that server is viewed has having more knowledge about the  
properties of values stored in its password store than the client.    
The client has no clue as to what encoding / preparation was used  
within the password store.

With PLAIN, the client lack of knowledge doesn't matter.  It simply  
provides the UTF-8 encoded Unicode password.  The server can sort it  
out.

But with CRAM-MD5, for independently implemented interoperability, the  
client must prepare the password for input into the cryptographic  
functions the same way the server does.   The client and server need  
to agree as to how to prepare the input to the cryptographic functions.

Note that RFC 4616 actually does detail why it used a SHOULD instead  
of a MUST.   I would argue that CRAM-MD5, for consideration on the  
Standard Track, do likewise.

One could argue that one could get away with something like:
    Except where the client and server have an a priori agreement to  
utilize a different character set, encoding, and/or preparation, the  
password MUST be represented using Unicode, prepared using SASLprep,  
and encoded as UTF-8 prior to input to the cryptographic functions.

Or alternatively as:
    The password SHOULD be represented using Unicode, prepared using  
SASLprep, and encoded as UTF-8 prior to input to the cryptographic  
functions.  Use of Unicode, SASLprep, and UTF-8 are not mandatory to  
allow clients and servers which have a priori agreements to use other  
character sets, character set encoding, and/or preparation to use  
whatever character sets, character set encoding, preparation they  
might agree to.  How a client and server might reach such an agreement  
is outside the scope of this specification.  It is also noted that  
such agreements will hinder interoperability with clients and servers  
strictly implement this specification (e.g., adhere to the above  
SHOULD).

As I noted when I recently brought up intended publication track of  
this I-D, one option is Standard Track with waiver.    The above text  
is basically asking for a waiver from the RFC 4422 requirement.

> In what way is the design of PLAIN different ?  Like CRAM-MD5 it
> sends the userid as plain text.

Unlike CRAM-MD5, PLAIN sends the password as plain text.

>
>
> Frank
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CKGgMF067757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 13:16:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CKGgbi067756; Tue, 12 Aug 2008 13:16:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CKGexE067746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 12 Aug 2008 13:16:41 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.209.112] (host-66-202-66-11.har.choiceone.net [66.202.66.11]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m7CKGa7h026603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 16:16:37 -0400 (EDT)
Date: Tue, 12 Aug 2008 16:16:32 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: Security
Message-ID: <[e-mail]>
In-Reply-To: <g7spon$np8$[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <g7spon$np8$[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, August 12, 2008 09:54:55 PM +0200 Frank Ellermann 
<[e-mail]> wrote:

>
> Kurt Zeilenga wrote:
>
>   [TLS]
>>> That places restrictions on specifications, not implementations,
>>> which is somewhat weird, but CRAM-MD5 could do the same.  That
>>> is what I propose to do.
>
>> I personally think such a change would be good.   I feel that TLS
>> recommendations to protect CRAM-MD5 ought to be the same as those
>> we made for the TLS protection of PLAIN.
>
> Could work.  What about existing protocols, has this to be limited
> to future specifications ?  Normally we say "SHOULD" when we mean
> "old stuff has a good excuse, its old".  IIRC there are a two old
> protocols with a mandatory CRAM-MD5, one of them (on demand relay)
> won't be updated anytime soon, if ever.

No, we say SHOULD when we mean "do this, unless you think you have a pretty 
good reason not to".  Occasionally we say SHOULD when we mean MUST but want 
implementations written prior to the specification that don't meet the 
requirement to be able to claim they are compliant with the spec. 
Generally this is a poor idea, because it also allows implementations 
written _after_ the specification to claim they are compliant.  In other 
situations we say SHOULD when we mean "MUST, but we know that some 
implementations will sometimes behave differently in order to interoperate 
with old stuff, which is a good reason".  In those cases, the goal is not 
to make the old stuff compliant, but to make it so new stuff can be 
compliant while still interoperating with the old stuff.


In this case, the requirement applies to protocol specifications, not 
implementations.  It's unnecessary to say SHOULD instead of MUST in this 
case, because doing so is not going to have any effect on existing 
published protocols, but may have the wrong effect on new protocols.


Incidentally, my recollection is that this is exactly the sort of situation 
that arose with making CRAM-MD5 "limited use".  We chose that designation 
because it was felt that the method should be avoided in new protocols in 
favor of whatever new thing we end up with, but there were some existing 
protocols that mandated it.  Again, "limited use" does not mean "not 
deployed" or "no one uses this"; it means "we don't think new uses of this 
are a good idea", along the same lines as a RFC2119 SHOULD NOT.


>> It works fine because of PLAIN's design.  The party, the server, is
>> preparing both the presented and stored strings.   In CRAM-MD5, two
>> parties need to agree on the preparation on what preparation to use
>> for things to work properly.
>
> I don't get this point.  A new user creating an account picks a
> free userid, and a password.  The details can vary, one way is
> online in a Web form.  If the server can note these credentials
> for PLAIN, it can also note it for CRAM-MD5 or other mechanisms,
> in any required format(s), even the somewhat odd "APR1" format.
>
> In what way is the design of PLAIN different ?  Like CRAM-MD5 it
> sends the userid as plain text.

PLAIN also sends the password as plain text.  CRAM-MD5 does not, so if the 
client does not encode the password correctly, there is nothing the server 
can do about 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 m7CK9pFM067035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 13:09:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CK9pi9067034; Tue, 12 Aug 2008 13:09:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CK9mlM067026 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 13:09:50 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KT0Bd-0003pc-US for [e-mail]; Tue, 12 Aug 2008 20:09:45 +0000
Received: from 212.82.251.8 ([212.82.251.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 20:09:45 +0000
Received: from nobody by 212.82.251.8 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 20:09:45 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Tue, 12 Aug 2008 22:10:33 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 14
Message-ID: <g7sqm1$r2a$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7r2et$50e$[e-mail]><[e-mail]><g7rl7f$kdl$[e-mail]><[e-mail]><g7ru9t$hrf$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.8
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu wrote:
=20
> Authors or others, please elaborate if you recall the
> history of this change.

I'm also curious, it was in all ID.ietf-sasl-crammd5=20
back to 2003, long before I started to read this list.

It was introduced in ID.nerenberg-sasl-crammd5-01:

<http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dhttp://tools.ie=
tf.org/id/draft-nerenberg-sasl-crammd5-01.txt>

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CJsIgo065566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 12:54:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CJsItl065565; Tue, 12 Aug 2008 12:54:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CJsEk4065553 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 12:54:16 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSzwZ-000395-F1 for [e-mail]; Tue, 12 Aug 2008 19:54:11 +0000
Received: from 212.82.251.8 ([212.82.251.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 19:54:11 +0000
Received: from nobody by 212.82.251.8 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 19:54:11 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Security
Date:  Tue, 12 Aug 2008 21:54:55 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 35
Message-ID: <g7spon$np8$[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.8
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

  [TLS]
>> That places restrictions on specifications, not implementations,
>> which is somewhat weird, but CRAM-MD5 could do the same.  That
>> is what I propose to do.
=20
> I personally think such a change would be good.   I feel that TLS
> recommendations to protect CRAM-MD5 ought to be the same as those
> we made for the TLS protection of PLAIN.

Could work.  What about existing protocols, has this to be limited
to future specifications ?  Normally we say "SHOULD" when we mean
"old stuff has a good excuse, its old".  IIRC there are a two old
protocols with a mandatory CRAM-MD5, one of them (on demand relay)
won't be updated anytime soon, if ever.

  [i18n]
>> SHOULD has worked fine for PLAIN, so I disagree.
>=20
> It works fine because of PLAIN's design.  The party, the server, is =20
> preparing both the presented and stored strings.   In CRAM-MD5, two =20
> parties need to agree on the preparation on what preparation to use =20
> for things to work properly.

I don't get this point.  A new user creating an account picks a
free userid, and a password.  The details can vary, one way is
online in a Web form.  If the server can note these credentials
for PLAIN, it can also note it for CRAM-MD5 or other mechanisms,
in any required format(s), even the somewhat odd "APR1" format.

In what way is the design of PLAIN different ?  Like CRAM-MD5 it
sends the userid as plain text. =20

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CIVrtP057692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 11:31:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CIVrQR057691; Tue, 12 Aug 2008 11:31:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CIVpG5057680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 11:31:52 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7CIVXFl064984; Tue, 12 Aug 2008 18:31:40 GMT (envelope-from [e-mail])
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: Security
Date: Tue, 12 Aug 2008 11:31:33 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
Sender: [e-mail]
Precedence: 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 12 Aug 2008, at 10:31 AM, Simon Josefsson wrote:
>> I have no seen adequate support for MUSTs here.
>
> Nor have I, but I don't believe MUST is required.  PLAIN contains:
>
>   By default, implementations SHOULD advertise and make use of the
>   PLAIN mechanism only when adequate data security services are in
>   place.
>
> It continues with:
>
>   Specifications for IETF protocols that indicate that this
>   mechanism is an applicable authentication mechanism MUST mandate  
> that
>   implementations support an strong data security service, such as  
> TLS.
>
> That places restrictions on specifications, not implementations, which
> is somewhat weird, but CRAM-MD5 could do the same.  That is what I
> propose to do.

I personally think such a change would be good.   I feel that TLS  
recommendations to protect CRAM-MD5 ought to be the same as those we  
made for the TLS protection of PLAIN.

>
>
>>> None of the arguments made in the
>>> document would still stand against that construct (I think).  What  
>>> is
>>> puzzling is that the document already appear to strongly suggest use
>>> of
>>> TLS and UTF-8 and SASLprep, so I think we have already solved the
>>> security and interoperability problem inherent in the old CRAM-MD5
>>> specification.
>>
>> I don't believe the SHOULDs are adequate to ensure independently
>> developed interoperability.
>
> SHOULD has worked fine for PLAIN, so I disagree.

It works fine because of PLAIN's design.  The party, the server, is  
preparing both the presented and stored strings.   In CRAM-MD5, two  
parties need to agree on the preparation on what preparation to use  
for things to work properly.

>
>
> /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 m7CICU77056362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 11:12:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CICUop056361; Tue, 12 Aug 2008 11:12:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CICTo9056349 for <[e-mail]>; Tue, 12 Aug 2008 11:12:30 -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 m7CICTtu012092 for <[e-mail]>; Tue, 12 Aug 2008 18:12:29 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 m7CICT4n023172 for <[e-mail]>; Tue, 12 Aug 2008 12:12:29 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7CICSRn015782; Tue, 12 Aug 2008 13:12:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7CICRCo015781; Tue, 12 Aug 2008 13:12:27 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 12 Aug 2008 13:12:27 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: tls-unique-using-prf considered harmful
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>, Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[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>

I was confused there for a second.  We don't have any registrations for
TLS channel bindings with this problem.  The existing unique TLS CB
types use TLS Finished messages and are not susceptible to this attack.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CHVtOk053318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 10:31:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CHVtDY053317; Tue, 12 Aug 2008 10:31:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 m7CHVqwb053306 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 10:31:54 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSxin-0005OP-UB; Tue, 12 Aug 2008 19:31:51 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080812:[e-mail]::53o389H2j9kN/bse:3mQc
X-Hashcash: 1:22:080812:[e-mail]::MdsRNkl/pWI7hx/Q:6prC
X-Hashcash: 1:22:080812:[e-mail]::1XG3bRYI0sgoufr/:GrsA
Date: Tue, 12 Aug 2008 19:31:49 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 12 Aug 2008 09:22:40 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On 12 Aug 2008, at 2:51 AM, Simon Josefsson wrote:
>
>>
>> Kurt Zeilenga <[e-mail]> writes:
>>
>>> On 14 Mar 2007, at 1:11 PM, Frank Ellermann wrote:
>>>
>>>>
>>>> | CRAM-MD5 is no longer considered to provide adequate protection.
>>>
>>> I believe the WG consensus supports the inclusion of this statement
>>> in
>>> the I-D, as well as the detailed consideration text that follows it.
>>>
>>>> That's not the case, as it depends on the circumstances where
>>>> CRAM-MD5 is used.  E.g. over TLS it could be fine (ignoring the
>>>> issue discussed in a separate thread wrt 2554bis), and CRAM-MD5
>>>> is certainly better than APOP (as stated in 2195) or "LOGIN".
>>
>> I believe Frank has a point here: CRAM-MD5 under TLS with server
>> authentication does not have any of the security problems mentioned in
>> section 5, at least as far as I can tell from a quick read of the -10
>> document.
>
> Which is why there is a recommendation that TLS be used.
>
> Given the mechanism can be used without TLS, detailing considerations
> for use without TLS seems quite appropriate.  It's also appropriate to
> discuss considerations for use with TLS.

Sure, but if CRAM-MD5 is used with TLS, the initial statement above is
misleading: there is nothing in the security considerations of CRAM-MD5
that explains how CRAM-MD5 under TLS fails to provide adequate
protection.

> It is my belief that WG consensus is that the current text is adequate
> in both of these areas.   I encourage anyone who thinks the current
> text can be approved upon offer alternative text for the WG to
> consider.

I suspect people read different things into the first statement here.  I
suggest to change it to:

  CRAM-MD5 used without TLS is no longer considered to provide adequate
  protection.

Otherwise it is unclear whether 'CRAM-MD5' refers to the actual
HMAC-mechanism used by CRAM-MD5 (then the sentence is true) or whether
it refers to CRAM-MD5 used under TLS (then the sentence is false).

>> CRAM-MD5 does have interoperability problems in that it historically
>> doesn't require use of UTF-8 and SASLPrep.  However, support for
>> SASLPrep in PLAIN was added in a later revision of PLAIN.  The same
>> could be done for UTF-8 and SASLprep in CRAM-MD5 too, which would
>> remove
>> that interoperability problems.
>
> Right, one could MUST Unicode, MUST SASLprep, MUST-UTF-8.   To date, I
> simply haven't seen significant WG support for changing the SHOULDs to
> MUSTs.

Agreed.  Note that PLAIN merely says that TLS SHOULD be used.  I believe
a SHOULD is sufficient, especially considering the good explanation of
the problems that leads to recommending TLS in the CRAM-MD5 document.

>> Summarizing, we could do for CRAM-MD5 what we did for PLAIN (require
>> TLS
>> and require UTF-8 + SASLprep).
>
> Because of CRAM-MD5 use of cryptographic functions, CRAM-MD5 requires
> more than what PLAIN requires.  PLAIN could get away with a server- 
> side SHOULD as it presumed the server knows what it might otherwise be
> able to do to ensure proper function.   With CRAM-MD5, the client
> traditionally has had to rely on a priori knowledge of the character
> sets/encoding/normalization to ensure proper function, and that means
> that one cannot independently produce an interoperable
> implementation.   If one desires independently developed
> interoperability, then providing a precise definition of the character
> encoding and normalization procedures is a necessary (as MUSTed by RFC
> 4422).  Such MUSTs would likely cause disruption.
>
> I have no seen adequate support for MUSTs here.

Nor have I, but I don't believe MUST is required.  PLAIN contains:

   By default, implementations SHOULD advertise and make use of the
   PLAIN mechanism only when adequate data security services are in
   place.

It continues with:

   Specifications for IETF protocols that indicate that this
   mechanism is an applicable authentication mechanism MUST mandate that
   implementations support an strong data security service, such as TLS.

That places restrictions on specifications, not implementations, which
is somewhat weird, but CRAM-MD5 could do the same.  That is what I
propose to do.

>> None of the arguments made in the
>> document would still stand against that construct (I think).  What is
>> puzzling is that the document already appear to strongly suggest use
>> of
>> TLS and UTF-8 and SASLprep, so I think we have already solved the
>> security and interoperability problem inherent in the old CRAM-MD5
>> specification.
>
> I don't believe the SHOULDs are adequate to ensure independently
> developed interoperability.

SHOULD has worked fine for PLAIN, so I disagree.

/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 m7CGrUYj049870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 09:53:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CGrU50049869; Tue, 12 Aug 2008 09:53:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CGrTWB049862 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 09:53:30 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7CGrTib009739 for <[e-mail]>; Tue, 12 Aug 2008 16:53:29 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7CGrTJS026038 for <[e-mail]>; Tue, 12 Aug 2008 10:53:29 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7CGrSf0015744; Tue, 12 Aug 2008 11:53:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7CGrRCI015743; Tue, 12 Aug 2008 11:53:27 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 12 Aug 2008 11:53:27 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>, Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: tls-unique-using-prf considered harmful
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>, Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Aug 12, 2008 at 10:43:28AM -0500, Nicolas Williams wrote:
> Good catch.  tls-unique-using-prf is ONLY OK IF Diffie-Hellman key
> agreement is used.  If RSA key transport is used then that channel
> binding is subject to trivial MITM attacks.
> 
> A TLS implementation, therefore, SHOULD NOT export the
> tls-unique-using-prf channel binding unless a suitable key exchange
> protocol was used.

Given that TLS unique CB is the only available CB type when using anon
DH suites I think that we can't merely declare TLS unique CB toxic.

Which CB to use, which CB is available, necessarily depends on knowledge
of what TLS cipher suite (or, more specifically, what key exchange
protocol) was used for the given channel.

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 m7CGX4Ro047929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 09:33:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CGX4J8047928; Tue, 12 Aug 2008 09:33: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 m7CGX3vd047919 for <[e-mail]>; Tue, 12 Aug 2008 09:33:03 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 17:32:59 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Future of SASLprep
Date: Tue, 12 Aug 2008 09:32:51 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 12 Aug 2008, at 3:16 AM, Simon Josefsson wrote:

>
> "Frank Ellermann" <[e-mail]> writes:
>
>> I'm fine with using SASLprep "everywhere" (incl. CRAM-MD5)
>> in SASL, or maybe switch to RFC 5198 "everywhere" when it
>> turns out that SASLprep is not implemented.
>
> Given how poor SASLprep works in practice (*), I think this could be
> discussed (but separately from CRAM-MD5).
>
> The IDNAbis effort seems now well under way, and it seems clear we
> cannot re-use much of their work since they abandon the StringPrep
> approach.

I think we can re-use, at a minimum, their approach for moving away =20
from StringPrep.

In revising RFC 4013, as I noted during the IETF#72 session, was to =20
rework SASLprep such that algorithm would not rely, to the extent =20
possible, tables tied to a particular version of Unicode but instead =20
rely largely on Unicode properties.  Like in the IDNAbis work, there =20
may be a need for an "exceptions" table.  Hopefully use of the =20
"exceptions" table will be limited to, well, truly exceptional cases.

It is my intent to SASprepbis to be produce the same output as =20
SASLprep when used with Unicode 3.2.

-- Kurt

> Passwords have quite different properties than domain names:
> it is normal and encouraged for passwords to contain characters from
> different scripts.  For example, some of the steps made by current
> SASLprep reduces entropy (e.g., translates =AA to a), which seems like =
a
> property we failed to discuss at the time.  We cannot re-use much of =20=

> the
> output from the IDNAbis design discussions either, because they are
> based on different assumptions.
>
> The discussions about Unicode versioning in RFC 5198 is better than in
> SASLprep.  Some elements of SASLprep, such as prohibiting certain
> non-printable characters is useful.
>
> Possibly SASLprep2 could be a profile of RFC 5198: applying certain
> algorithmic tests to restrict some characters on top of the RFC 5198
> output.
>
> /Simon
>
> (*) Primarily because of the restriction to Unicode 3.2, but partly
> because it hasn't been widely implemented.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CGMjNk047063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 09:22:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CGMjub047062; Tue, 12 Aug 2008 09:22:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CGMhol047054 for <[e-mail]>; Tue, 12 Aug 2008 09:22:44 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 17:22:42 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Simon Josefsson <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Security
Date: Tue, 12 Aug 2008 09:22:40 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
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 12 Aug 2008, at 2:51 AM, Simon Josefsson wrote:

>
> Kurt Zeilenga <[e-mail]> writes:
>
>> On 14 Mar 2007, at 1:11 PM, Frank Ellermann wrote:
>>
>>>
>>> | CRAM-MD5 is no longer considered to provide adequate protection.
>>
>> I believe the WG consensus supports the inclusion of this statement  
>> in
>> the I-D, as well as the detailed consideration text that follows it.
>>
>>> That's not the case, as it depends on the circumstances where
>>> CRAM-MD5 is used.  E.g. over TLS it could be fine (ignoring the
>>> issue discussed in a separate thread wrt 2554bis), and CRAM-MD5
>>> is certainly better than APOP (as stated in 2195) or "LOGIN".
>
> I believe Frank has a point here: CRAM-MD5 under TLS with server
> authentication does not have any of the security problems mentioned in
> section 5, at least as far as I can tell from a quick read of the -10
> document.

Which is why there is a recommendation that TLS be used.

Given the mechanism can be used without TLS, detailing considerations  
for use without TLS seems quite appropriate.  It's also appropriate to  
discuss considerations for use with TLS.

It is my belief that WG consensus is that the current text is adequate  
in both of these areas.   I encourage anyone who thinks the current  
text can be approved upon offer alternative text for the WG to consider.

> CRAM-MD5 does have interoperability problems in that it historically
> doesn't require use of UTF-8 and SASLPrep.  However, support for
> SASLPrep in PLAIN was added in a later revision of PLAIN.  The same
> could be done for UTF-8 and SASLprep in CRAM-MD5 too, which would  
> remove
> that interoperability problems.

Right, one could MUST Unicode, MUST SASLprep, MUST-UTF-8.   To date, I  
simply haven't seen significant WG support for changing the SHOULDs to  
MUSTs.

> Summarizing, we could do for CRAM-MD5 what we did for PLAIN (require  
> TLS
> and require UTF-8 + SASLprep).

Because of CRAM-MD5 use of cryptographic functions, CRAM-MD5 requires  
more than what PLAIN requires.  PLAIN could get away with a server- 
side SHOULD as it presumed the server knows what it might otherwise be  
able to do to ensure proper function.   With CRAM-MD5, the client  
traditionally has had to rely on a priori knowledge of the character  
sets/encoding/normalization to ensure proper function, and that means  
that one cannot independently produce an interoperable  
implementation.   If one desires independently developed  
interoperability, then providing a precise definition of the character  
encoding and normalization procedures is a necessary (as MUSTed by RFC  
4422).  Such MUSTs would likely cause disruption.

I have no seen adequate support for MUSTs here.

> None of the arguments made in the
> document would still stand against that construct (I think).  What is
> puzzling is that the document already appear to strongly suggest use  
> of
> TLS and UTF-8 and SASLprep, so I think we have already solved the
> security and interoperability problem inherent in the old CRAM-MD5
> specification.

I don't believe the SHOULDs are adequate to ensure independently  
developed interoperability.

>
>
> /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 m7CFhZ7u043638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 08:43:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CFhZsD043637; Tue, 12 Aug 2008 08:43:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 m7CFhY28043630 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 08:43:35 -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 m7CFhXsa019900 for <[e-mail]>; Tue, 12 Aug 2008 15:43:34 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 m7CFhXuW055228 for <[e-mail]>; Tue, 12 Aug 2008 09:43:33 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7CFhWBh015683; Tue, 12 Aug 2008 10:43:32 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7CFhSY9015682; Tue, 12 Aug 2008 10:43:28 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 12 Aug 2008 10:43:28 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: tls-unique-using-prf considered harmful
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>, Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[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>

Good catch.  tls-unique-using-prf is ONLY OK IF Diffie-Hellman key
agreement is used.  If RSA key transport is used then that channel
binding is subject to trivial MITM attacks.

A TLS implementation, therefore, SHOULD NOT export the
tls-unique-using-prf channel binding unless a suitable key exchange
protocol was used.

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 m7CFfMhs043493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 08:41:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CFfMYY043492; Tue, 12 Aug 2008 08:41:22 -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 m7CFfKv9043485 for <[e-mail]>; Tue, 12 Aug 2008 08:41:21 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 16:41:19 +0100
X-SMTP-Protocol-Errors: NORDNS
From: Kurt Zeilenga <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
In-Reply-To: <006b01c8fbfe$fa2c95b0$14fb52d4@xyzzy>
Subject: Re: Interoperability
X-Priority: 3
References: <006b01c8fbfe$fa2c95b0$14fb52d4@xyzzy>
Message-Id: <[e-mail]>
Date: Tue, 12 Aug 2008 08:41:16 -0700
Cc: [e-mail], Tom Yu <[e-mail]>, [e-mail]
X-Mailer: Apple Mail (2.924)
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 11 Aug 2008, at 3:09 PM, Frank Ellermann wrote:

> I appeal that decision.

It is my understanding, based upon your off-the-list comments, that  
this appeal is filed with our AD, Pasi Eronen, and not with the chairs  
of the SASL WG.   As such, no further chair action is required or  
appropriate at this time with regard to the appeal itself.

It is noted that work on the I-D should continue (including in areas  
possibly impacted by the outcome of the appeal).

-- 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 m7CFciqa043327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 08:38:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CFcikS043326; Tue, 12 Aug 2008 08:38:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CFcg0U043316 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 08:38:43 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSvxJ-0000fA-EB for [e-mail]; Tue, 12 Aug 2008 15:38:41 +0000
Received: from 212.82.251.163 ([212.82.251.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 15:38:41 +0000
Received: from nobody by 212.82.251.163 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 15:38:41 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Interoperability
Date:  Tue, 12 Aug 2008 17:39:29 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 19
Message-ID: <g7sapp$vkh$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7qd9g$lvi$[e-mail]> <[e-mail]><g7r3l6$728$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.163
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman wrote:
=20
> You need to appeal to Kurt and tom before you can appeal
> anything to Pasi.

They'll tell me if something isn't as RFC 2026 6.1.5 wants
it.  I think it is clear enough what the dispute is about,
Kurt and I already discussed it on and off list, and what
might help now is somebody with a fresh view on the issue.

That is what "dispute resolution" is about, plus the known
fact that you never get what you asked for, therefore don't
ask if you are not ready for an answer. =20

(For a philosophical debate about the magic word consensus
 and IETF dispute resolution procedures let's jump to the
 general list, they're used to have CRAM-MD5 as show case)

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CFZZAB043125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 08:35:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CFZZqp043124; Tue, 12 Aug 2008 08:35:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CFZY51043117 for <[e-mail]>; Tue, 12 Aug 2008 08:35:34 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7CFZXo7010045 for <[e-mail]>; Tue, 12 Aug 2008 15:35:33 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7CFZXCu050769 for <[e-mail]>; Tue, 12 Aug 2008 09:35:33 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7CFZW6V015668; Tue, 12 Aug 2008 10:35:32 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7CFZNlR015667; Tue, 12 Aug 2008 10:35:23 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 12 Aug 2008 10:35:23 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: ABNF for the three cases of GS2
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 11, 2008 at 05:47:39PM -0400, Sam Hartman wrote:
>     Nicolas> If Chris doesn't mind the RFC2743 pseudo-ASN.1 OID +
>     Nicolas> length header, then let's keep it.  Otherwise let's
>     Nicolas> compress it in GS2.
> 
> I thought Chris minded the fact that it is a non-constant string with
> a DER length covering the entire context token.
> 
> My preference is to update 2743 to allow the length in that encoding
> to cover either the entire token or the oid as defined by the
> mechanism spec.

!

> If we cannot make that fly either because of interop problems or
> consensus problems to compress in GS2.

I'd rather just compress it in GS2 (on all context tokens).  The code
needed to do it pretty much necessarily exists in various GSS
implementations, and can either be made a public API or copy-pasted into
GS2 implementations.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CFM0kH041665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 08:22:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CFM0oj041664; Tue, 12 Aug 2008 08:22:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 m7CFLw5V041657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 08:21:59 -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 m7CFLuDo014631; Tue, 12 Aug 2008 11:21:56 -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 m7CFLtku015573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Aug 2008 11:21:55 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m7CFLt8a026305; Tue, 12 Aug 2008 11:21:55 -0400 (EDT)
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Random data
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <g7rl7f$kdl$[e-mail]> <[e-mail]> <g7ru9t$hrf$[e-mail]>
From: Tom Yu <[e-mail]>
Date: Tue, 12 Aug 2008 11:21:55 -0400
In-Reply-To: <g7ru9t$hrf$[e-mail]> (Frank Ellermann's message of "Tue, 12 Aug 2008 14:06:13 +0200")
Message-ID: <[e-mail]>
Lines: 30
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> Tom Yu wrote:
>
>>> The right hand side of a challenge in "Message-ID format"
>>> can be twisted into what I expect by an attacker, it's no
>>> security feature.
>  
>> Might this have been an aborted attempt at specifying how
>> to use the challenge to transmit additional information to
>> a server, such as channel binding information?  Or am I
>> thinking of DIGEST?
>
> I'd guess that RFC 2195 uses the format of a Message-ID for
> a challenge, because that's what APOP also uses, and a known
> (for mail and news related protocols) concept.

I meant that the introduction in draft-ietf-sasl-crammd5 of a new
requirement that an implementation not interpret the "string that
RFC2195 required to look like a RFC822 msg-id" might have been an
aborted attempt to provide a "covert channel" for signaling the use of
a channel binding.

Alternatively, the new requirement that the client not interpret the
challenge string might be an effort to improve interoperability with
servers that do not send challenge strings that strictly conform to
the syntax of RFC822 or RFC2822 msg-id strings.

Authors or others, please elaborate if you recall the history of this
change.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CEiEP5038545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 07:44:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CEiEKX038544; Tue, 12 Aug 2008 07:44: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 m7CEiC7b038538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 07:44:13 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSv6T-0005NF-Jo; Tue, 12 Aug 2008 16:44:08 +0200
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: tls-unique-using-prf considered harmful
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[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:080812:[e-mail]::nI/GCtQ72YsCyD2i:1EsB
X-Hashcash: 1:22:080812:[e-mail]::MubAzJuvJbVVNsai:1jKF
X-Hashcash: 1:22:080812:[e-mail]::IFNiYz6AQPxSF49Q:5FhW
X-Hashcash: 1:22:080812:[e-mail]::7VKOp4tAaLJijNei:9SjM
X-Hashcash: 1:22:080812:[e-mail]::XOZJiDIcGb84JtaY:EROx
Date: Tue, 12 Aug 2008 16:44:03 +0200
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Tue, 12 Aug 2008 09:21:58 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman <[e-mail]> writes:

>>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:
>
>     Simon> Sam Hartman <[e-mail]> writes:
>     Simon> bindings, such as a 'tls-unique-using-prf' that use the TLS
>     Simon> PRF instead of the TLS Finished messages.
>
> Simon, I've been meaning to write this up for the channel binding
> list, but since you bring it up I'll briefly describe.  A group of us
> met in Dublin over lunch to discuss Kerberos FAST.  As we ran into
> problems, we started comparing to other protocols.  It ended up that
> one of the things we looked at was TLS, and one of the complicated
> things we looked at was a channel binding using the TLS PRF.
>
> It turns out that fails to meet the definition of channel bindings for
> most TLS ciphers.  RFC 5056 requires that it be difficult for an
> attacker to manipulate a connection such that two channels have the
> same unique channel bindings.
>
> As I recall, the TLS master secret (which keys the PRF) is based only
> on the pre-master secret, the client random value and the server
> random value.
>
> Alice connects to a MITM.  She's going to use TLS with one of the
> traditional RSA ciphers.  She doesn't check certificates because she's
> relying on channel binding and some later authentication.  She really
> wanted to be connecting to Bob rather than the MITM.  
>
> In her first message she sends her client value.  The MITM connects to
> Bob, sends the same client random value that Alice sent and receives
> Bob's random value in the server hello.  The MITM sends a server hello
> back to Alice using the same random value.  The MITM sends along a
> certificate message for the certificate that the MITM knows the private key to.  
>
> Alice encrypts the pre-master secret in the MITM's key and sends it
> along.  The MITM decrypt the pre-master secret, encrypts it in Bob's
> key and sends it along.  TLS establishment proceeds as normal.
>
> Note that the channel has the same name using a unique-prf binding but
> not using a unique-finish binding.  I was very surprised when I
> discovered this.  I had previously believed that tls-unique and
> tls-unique-prf had the same security properties.  

Good writeup.

This was discussed before, although without the complete writeup of the
attack.  As a response I proposed a variation that combines what I
believe are the best properties of both TLS-PRF and the TLS Finished
approach in.  See earlier discussion in the SASL WG under the "TLS
channel bindings" subject:

http://thread.gmane.org/gmane.ietf.sasl/2329/focus=2330

I've updated draft-josefsson-sasl-tls-cb to implement these ideas, using
this construct:

    TLS_channel_bindings =
       PRF(SecurityParameters.master_secret,
           "channel binding",
           MD5(handshake_messages) + SHA-1(handshake_messages)) [0..31]

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 m7CEMXFc036752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 07:22:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CEMX8D036751; Tue, 12 Aug 2008 07:22:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CEMPjJ036727 for <[e-mail]>; Tue, 12 Aug 2008 07:22:32 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 12F8541EF; Tue, 12 Aug 2008 10:22:22 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Interoperability
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]> <[e-mail]> <g7r3l6$728$[e-mail]>
Date: Tue, 12 Aug 2008 10:22:22 -0400
In-Reply-To: <g7r3l6$728$[e-mail]> (Frank Ellermann's message of "Tue, 12 Aug 2008 06:31:14 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Frank> Sam Hartman wrote:

    >> it is generally advisable to make it clear whether you are
    >> appealing the process--in this case arguing that the WG did not
    >> have the consensus Kurt claims it does--or appealing the
    >> technical decsion--arguing that the WG is wrong.

    Frank> ACK.  There were some off list messages meanwhile, and I
    Frank> hope that Pasi now has enough facts to figure out what it's
    Frank> about:

    Frank> I'm not aware of any interop issues wrt RFC 2195, and I
    Frank> don't consider CRAM-MD5 as a hopeless case.  I also
    Frank> couldn't say that DIGEST-MD5 is hopeless, but it is
    Frank> certainly worse than CRAM-MD5 wrt interoperability.

You need to appeal to Kurt and tom before you can appeal anything to
Pasi.  With one exception in RFC 3005, IETF appeals start with the
party whose decision you disagree with.

(I personally think the chairs should require you to publically state
the substance of your appeal, not handle it off-list)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CDM6hZ031819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 06:22:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CDM6pc031818; Tue, 12 Aug 2008 06:22:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CDM4iR031812 for <[e-mail]>; Tue, 12 Aug 2008 06:22:05 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AD23541EF; Tue, 12 Aug 2008 09:21:58 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: tls-unique-using-prf considered harmful
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 12 Aug 2008 09:21:58 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Tue, 12 Aug 2008 12:39:13 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Simon> Sam Hartman <[e-mail]> writes:
    Simon> bindings, such as a 'tls-unique-using-prf' that use the TLS
    Simon> PRF instead of the TLS Finished messages.

Simon, I've been meaning to write this up for the channel binding
list, but since you bring it up I'll briefly describe.  A group of us
met in Dublin over lunch to discuss Kerberos FAST.  As we ran into
problems, we started comparing to other protocols.  It ended up that
one of the things we looked at was TLS, and one of the complicated
things we looked at was a channel binding using the TLS PRF.

It turns out that fails to meet the definition of channel bindings for
most TLS ciphers.  RFC 5056 requires that it be difficult for an
attacker to manipulate a connection such that two channels have the
same unique channel bindings.

As I recall, the TLS master secret (which keys the PRF) is based only
on the pre-master secret, the client random value and the server
random value.

Alice connects to a MITM.  She's going to use TLS with one of the
traditional RSA ciphers.  She doesn't check certificates because she's
relying on channel binding and some later authentication.  She really
wanted to be connecting to Bob rather than the MITM.  

In her first message she sends her client value.  The MITM connects to
Bob, sends the same client random value that Alice sent and receives
Bob's random value in the server hello.  The MITM sends a server hello
back to Alice using the same random value.  The MITM sends along a
certificate message for the certificate that the MITM knows the private key to.  

Alice encrypts the pre-master secret in the MITM's key and sends it
along.  The MITM decrypt the pre-master secret, encrypts it in Bob's
key and sends it along.  TLS establishment proceeds as normal.

Note that the channel has the same name using a unique-prf binding but
not using a unique-finish binding.  I was very surprised when I
discovered this.  I had previously believed that tls-unique and
tls-unique-prf had the same security properties.  



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CDC3aG031003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 06:12:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CDC3k4031002; Tue, 12 Aug 2008 06:12:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CDBxJq030985 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 06:12:02 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KStfL-0002FX-GU for [e-mail]; Tue, 12 Aug 2008 13:11:59 +0000
Received: from 212.82.251.163 ([212.82.251.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 13:11:59 +0000
Received: from nobody by 212.82.251.163 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 13:11:59 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Future of SASLprep
Date:  Tue, 12 Aug 2008 15:12:47 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 35
Message-ID: <g7s26n$v7o$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7qd9g$lvi$[e-mail]> <[e-mail]><g7rqp5$6n2$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.163
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>> What further restrictions do you have in mind ?
=20
> See RFC 4013 section 2.3 and RFC 3454 section 3.1.

Okay, RFC 5198 might be not radical enough with C0 controls.

If users insist on trying the icon of a fruit (private use)
in their passwords they need a warning that this might be=20
difficult to produce on other platforms.  And if they then
still insist on it they have been warned.

Similar case:  One password I need for 'runas' (a kind of
'sudo' for NT) has the funny feature that I can't input it
on a command line.  OTOH it's perfectly non-ASCII.

Some sets in RFC 4013 2.3 are also eliminated in RFC 5198,
e.g., surrogates.  The BOM in RFC 3454 3.1 is a MUST NOT
in RFC 5198, anything else in RFC 3454 is not *obviously*
critical from my POV, e.g., SHY.

> However, some of them may make sense in order to avoid
> display or implementation issues (e.g., change-display
> properties and tagging characters).

Okay, RFC 5198 says the other side should be prepared to
handle the difference between SHOULD NFC and "MUST", this
handler might be confused by invalid tagging attempts...

...on the other hand this WG can't "fix Unicode" for its
purposes.  If we'd want that we could keep SASLprep as is,
maybe updating it to Unicode 5.1.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CC5VoO025867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 05:05:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CC5VZn025866; Tue, 12 Aug 2008 05:05:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CC5Sth025859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 05:05:29 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSscw-0007fJ-5X for [e-mail]; Tue, 12 Aug 2008 12:05:26 +0000
Received: from 212.82.251.163 ([212.82.251.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 12:05:26 +0000
Received: from nobody by 212.82.251.163 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 12:05:26 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Tue, 12 Aug 2008 14:06:13 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 16
Message-ID: <g7ru9t$hrf$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7r2et$50e$[e-mail]><[e-mail]><g7rl7f$kdl$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.163
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu wrote:

>> The right hand side of a challenge in "Message-ID format"
>> can be twisted into what I expect by an attacker, it's no
>> security feature.
=20
> Might this have been an aborted attempt at specifying how
> to use the challenge to transmit additional information to
> a server, such as channel binding information?  Or am I
> thinking of DIGEST?

I'd guess that RFC 2195 uses the format of a Message-ID for
a challenge, because that's what APOP also uses, and a known
(for mail and news related protocols) concept.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CBvk7Y025214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 04:57:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CBvkL5025213; Tue, 12 Aug 2008 04:57: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 m7CBvh78025207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 04:57:45 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSsVO-0005M1-N7; Tue, 12 Aug 2008 13:57:40 +0200
From: Simon Josefsson <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Future of SASLprep
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]> <[e-mail]> <g7rqp5$6n2$[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080812:[e-mail]::KlA6O9xoRD+Oy5E0:6/PU
X-Hashcash: 1:22:080812:[e-mail]::ed82HLkjnbRghMbR:IKQJ
Date: Tue, 12 Aug 2008 13:57:36 +0200
In-Reply-To: <g7rqp5$6n2$[e-mail]> (Frank Ellermann's message of "Tue, 12 Aug 2008 13:06:05 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>> Possibly SASLprep2 could be a profile of RFC 5198: applying
>> certain algorithmic tests to restrict some characters on
>> top of the RFC 5198 output.
>
> Simplified RFC 5198 is UTF-8 NFC minus some control chars.
> What further restrictions do you have in mind ?

See RFC 4013 section 2.3 and RFC 3454 section 3.1.  I'm sure that some
of those prohibited characters are a bad idea for passwords (because the
prohibited characters would have added entropy).  However, some of them
may make sense in order to avoid display or implementation issues (e.g.,
change-display properties and tagging characters).

/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 m7CBcKkc023655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 04:38:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CBcKO2023654; Tue, 12 Aug 2008 04:38:20 -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 m7CBcIhh023645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 04:38:19 -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 m7CBcFmS016226; Tue, 12 Aug 2008 07:38:15 -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 m7CBcE8Q013858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Aug 2008 07:38:15 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id m7CBcETP023842; Tue, 12 Aug 2008 07:38:14 -0400 (EDT)
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Random data
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <g7rl7f$kdl$[e-mail]>
From: Tom Yu <[e-mail]>
Date: Tue, 12 Aug 2008 07:38:14 -0400
In-Reply-To: <g7rl7f$kdl$[e-mail]> (Frank Ellermann's message of "Tue, 12 Aug 2008 11:31:20 +0200")
Message-ID: <[e-mail]>
Lines: 34
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> Kurt Zeilenga wrote:
>
>> I ignored the "without channel bindings" phrases in your  
>> question as neither PLAIN nor CRAM-MD5 provide channel
>> bindings.
>
> Good, that is what I meant.  Likely I'm mistaken, but one
> point of channel bindings appears to be an answer to the
> question "am I talking with the site I wish to talk with"
> (as opposed to a MITM). 

As I recall, the server cares about MITM as well.  TLS without channel
bindings may give the client assurance about who it is talking to,
given adequate validation of the server certificate, but without an
adequately validated client certificate, the server does not know that
it is not communicating with a MITM posing as the client.

> Even if that is an unrelated issue, PLAIN can't be a good
> plan when I'm not sure about the other side. 
>
> The right hand side of a challenge in "Message-ID format"
> can be twisted into what I expect by an attacker, it's no
> security feature.

Might this have been an aborted attempt at specifying how to use the
challenge to transmit additional information to a server, such as
channel binding information?  Or am I thinking of DIGEST?

> I just wondered s/21/17/ months ago why the draft insists
> on ignoring the format of the challenge with new MUSTard.
>
>  Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CB5S0I020434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 04:05:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CB5STv020433; Tue, 12 Aug 2008 04:05:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CB5ORS020411 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 04:05:26 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSrgl-0004oy-DY for [e-mail]; Tue, 12 Aug 2008 11:05:19 +0000
Received: from 212.82.251.163 ([212.82.251.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 11:05:19 +0000
Received: from nobody by 212.82.251.163 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 11:05:19 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Future of SASLprep
Date:  Tue, 12 Aug 2008 13:06:05 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 25
Message-ID: <g7rqp5$6n2$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7qd9g$lvi$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.163
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

> Passwords have quite different properties than domain names:
> it is normal and encouraged for passwords to contain characters
> from different scripts.

Yes.  Recently I looked into a years old archive about the
creation of tables inverting simple passwords from various
forms (incl. MD5), and the various pre-configured subsets
of supported characters where limited to what you'd see on
US keyboard layouts.

The size of the tables and the time to compute them (once)
increased dramatically with the number of supported input
characters.  That's (in theory) no obsctacle for say 128
characters, it could be hopeless for 100,000 characters...

> Possibly SASLprep2 could be a profile of RFC 5198: applying
> certain algorithmic tests to restrict some characters on
> top of the RFC 5198 output.

Simplified RFC 5198 is UTF-8 NFC minus some control chars.
What further restrictions do you have in mind ?

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CAdLrw018717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 03:39:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CAdLal018716; Tue, 12 Aug 2008 03:39:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 m7CAdIp4018706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 03:39:20 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSrHW-0005Ku-4S; Tue, 12 Aug 2008 12:39:15 +0200
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[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:080812:[e-mail]::58EV+ZsJoWzjWBBx:KjeF
X-Hashcash: 1:22:080812:[e-mail]::2IgyIg769bkv1pP9:IbgV
X-Hashcash: 1:22:080812:[e-mail]::Md544AwYa2dzAx4b:sa6U
X-Hashcash: 1:22:080812:[e-mail]::DgAKloiKVFpIFo0u:eLRL
X-Hashcash: 1:22:080812:[e-mail]::Y9ZvSNzjuzSEeltU:m5zB
Date: Tue, 12 Aug 2008 12:39:13 +0200
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Mon, 11 Aug 2008 21:30:19 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman <[e-mail]> writes:

>>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:
>     >> And of course there is the encoded channel bindings (the
>     >> b64-cb-data), which I'll understand as soon as I've read up on
>     >> channel bindings:-)
>
>     Simon> Possibly it is of no use, and only the channel binding name
>     Simon> is needed.  By sending a HMAC blob using the channel
>     Simon> bindings as key you may get some other properties, but I'm
>     Simon> less certain there is any significant motivation to do
>     Simon> this.  I'm not even sure we need to depend on the channel
>     Simon> binding vehicle.  The EXTERNAL-CHANNEL mechanism could be
>     Simon> renamed to EXTERNAL-TLS and be made specific to refer to
>     Simon> the outer TLS channel inside the application protocol, and
>     Simon> the client credentials negotiated in that TLS session.
> If you send channel bindings, the point would presumably be to
> distinguish between two channels of the same type that both exist.  I
> think that might be useful.  I don't think you can get any security
> properties out of channel bindings without also doing an
> authentication at the layer that is exchanging channel bindings.
>
> However channel bindings can be a good name for a channel.  Note that
> in some cases the name is not unique.  Also, in some cases the name
> must be kept confidential.

Further, there are potential for confusion because of the
non-uniqueness: for example, there are channel bindings 'tls-unique' and
'tls-unique-for-telnet'.  Both applies to a TLS channel, but one is
protocol-agnostic and one is intended for use in telnet.  If telnet used
TLS and SASL, both tls-unique and tls-unique-for-telnet could be
accepted by the server to mean "the outer TLS channel".  But maintaining
this mapping appears complex and error prone.  Especially considering
the potential for future channel bindings, such as a
'tls-unique-using-prf' that use the TLS PRF instead of the TLS Finished
messages.

When is it useful to be able to identify one out of two channels of the
same type?  IPSEC may be the use-case, although I wonder whether the
client credentials used for IPSEC are ever useful for SASL applications.

At this point, I'm leaning towards renaming the mechanism to
EXTERNAL-CLIENT-TLS and specify that it refers to the outer TLS channel
as negotiated by the application protocol using a STARTTLS mechanism,
and that it is only applicable when the outer TLS channel has negotiated
client authentication (otherwise EXTERNAL is more appropriate).  That
appears simpler to specify and implement than to re-use the channel
bindings mechanism.  To sway me, I'd appreciate an example of some
useful use-case that the EXTERNAL-CLIENT-TLS approach would fail to
address but that a EXTERNAL-CHANNEL-like approach would address.

Hm.  Maybe I just realized one such example: IMAP+STARTTLS over a
TLS-VPN?  I'm not sure it is a useful example though.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CAPTNT018081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 03:25:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CAPTWH018080; Tue, 12 Aug 2008 03:25:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-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 m7CAPRYB018074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 03:25:28 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSr44-0005Kg-Tg; Tue, 12 Aug 2008 12:25:25 +0200
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: ABNF for the three cases of GS2
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080812:[e-mail]::fntP4xeTiKCjIe48:6LK3
X-Hashcash: 1:22:080812:[e-mail]::Xm8A6OS1ZGumFJje:Ap8d
Date: Tue, 12 Aug 2008 12:25:19 +0200
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Mon, 11 Aug 2008 17:14:33 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman <[e-mail]> writes:

> I have put together ABNF for the three cases of GS2.

Thanks for doing this.

> My current preference is a moderate preference for case 2.  I might
> like case 3 better if someone suggested a better way to determine the
> end of the non-context part.

I have a preference for case 1: while wasting 33% of the size, it uses
known encoding that are easily accessible in many languages.

I think an encoder for the (likely non-reusable) escape mechanism in
case 2 will create more complexity and will be trickier to get right.

I don't care strongly about this, but I think case 2 will look "uglier".

/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 m7CAGYI1017504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 03:16:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CAGYKM017503; Tue, 12 Aug 2008 03:16:34 -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 m7CAGUDn017492 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 03:16:32 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSqvV-0005KZ-9Q for [e-mail]; Tue, 12 Aug 2008 12:16:30 +0200
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Future of SASLprep
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080812:[e-mail]::CKWcxkUnbb0FLPG9:UIcA
X-Hashcash: 1:22:080812:[e-mail]::5noYD4+jY9cQ5FVk:Zh08
Date: Tue, 12 Aug 2008 12:16:28 +0200
In-Reply-To: <g7qd9g$lvi$[e-mail]> (Frank Ellermann's message of "Tue, 12 Aug 2008 00:09:45 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> I'm fine with using SASLprep "everywhere" (incl. CRAM-MD5)
> in SASL, or maybe switch to RFC 5198 "everywhere" when it
> turns out that SASLprep is not implemented.

Given how poor SASLprep works in practice (*), I think this could be
discussed (but separately from CRAM-MD5).

The IDNAbis effort seems now well under way, and it seems clear we
cannot re-use much of their work since they abandon the StringPrep
approach.  Passwords have quite different properties than domain names:
it is normal and encouraged for passwords to contain characters from
different scripts.  For example, some of the steps made by current
SASLprep reduces entropy (e.g., translates ª to a), which seems like a
property we failed to discuss at the time.  We cannot re-use much of the
output from the IDNAbis design discussions either, because they are
based on different assumptions.

The discussions about Unicode versioning in RFC 5198 is better than in
SASLprep.  Some elements of SASLprep, such as prohibiting certain
non-printable characters is useful.

Possibly SASLprep2 could be a profile of RFC 5198: applying certain
algorithmic tests to restrict some characters on top of the RFC 5198
output.

/Simon

(*) Primarily because of the restriction to Unicode 3.2, but partly
because it hasn't been widely implemented.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C9pmGO014723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 02:51:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C9pmOP014722; Tue, 12 Aug 2008 02:51: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 m7C9pjpQ014714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 02:51:47 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSqXX-0005K7-9Z; Tue, 12 Aug 2008 11:51:44 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Security
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080812:[e-mail]::8zpfbGrf14fDvxqM:1fQx
X-Hashcash: 1:22:080812:[e-mail]::pszvvHXzCnFdwDgm:3ttv
X-Hashcash: 1:22:080812:[e-mail]::oaTl3umzQ2A4nW+T:5hos
Date: Tue, 12 Aug 2008 11:51:43 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Mon, 11 Aug 2008 18:44:16 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On 14 Mar 2007, at 1:11 PM, Frank Ellermann wrote:
>
>>
>> | CRAM-MD5 is no longer considered to provide adequate protection.
>
> I believe the WG consensus supports the inclusion of this statement in
> the I-D, as well as the detailed consideration text that follows it.
>
>> That's not the case, as it depends on the circumstances where
>> CRAM-MD5 is used.  E.g. over TLS it could be fine (ignoring the
>> issue discussed in a separate thread wrt 2554bis), and CRAM-MD5
>> is certainly better than APOP (as stated in 2195) or "LOGIN".

I believe Frank has a point here: CRAM-MD5 under TLS with server
authentication does not have any of the security problems mentioned in
section 5, at least as far as I can tell from a quick read of the -10
document.

CRAM-MD5 does have interoperability problems in that it historically
doesn't require use of UTF-8 and SASLPrep.  However, support for
SASLPrep in PLAIN was added in a later revision of PLAIN.  The same
could be done for UTF-8 and SASLprep in CRAM-MD5 too, which would remove
that interoperability problems.

Summarizing, we could do for CRAM-MD5 what we did for PLAIN (require TLS
and require UTF-8 + SASLprep).  None of the arguments made in the
document would still stand against that construct (I think).  What is
puzzling is that the document already appear to strongly suggest use of
TLS and UTF-8 and SASLprep, so I think we have already solved the
security and interoperability problem inherent in the old CRAM-MD5
specification.

/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 m7C9YUuE013696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 02:34:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C9YUvK013695; Tue, 12 Aug 2008 02:34: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 m7C9YSOd013689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 02:34:30 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-126-5.bredband.comhem.se ([80.216.126.5] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1KSqGk-0005Jl-TX; Tue, 12 Aug 2008 11:34:23 +0200
From: Simon Josefsson <[e-mail]>
To: Lyndon Nerenberg <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Random data
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080812:[e-mail]::LfrbfDa+VIeGIGlr:0I2O
X-Hashcash: 1:22:080812:[e-mail]::wEfWpUkpiLle7qLn:2LJm
X-Hashcash: 1:22:080812:[e-mail]::X6x/g6/x46yCWI1Y:Hltg
X-Hashcash: 1:22:080812:[e-mail]::htSjgjd2dJ+J1VvL:OKGG
Date: Tue, 12 Aug 2008 11:34:22 +0200
In-Reply-To: <[e-mail]> (Lyndon Nerenberg's message of "Mon, 11 Aug 2008 22:35:22 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.7 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lyndon Nerenberg <[e-mail]> writes:

>> Depends on which traits one thinks are desirable.   In general, I
>> would say that CRAM-MD5 offers slightly better security than PLAIN,
>> while PLAIN offers better ability to support external/legacy
>> password stores, proxy-authz, etc.
>
> Where is the peer reviewed analysis of CRAM-MD5 vs. PLAIN that
> everyone alludes to? A simple reference to it in son-of-2195 would
> solve this argument.

I'm not aware of any existing good analysis of C vs P, but a comparison
can be made in a table.  Here is a starting point.  Questions of the
applicability of PLAIN vs CRAM-MD5 often comes up in deployment
discussions, so I agree that adding it to 2195bis would be a good thing.
This straw-man needs to be expanded and reviewed carefully though.


                        PLAIN               CRAM-MD5

Support for
Authorization             Yes                  No
Identity

Transfers
Passwords
in Clear Text             Yes (*)              No

Compatible with
hashed password           Yes                  No
databases, such
as Unix
/etc/shadow (**)

Requires a
mechanism-                Yes                  No
specific
password database (**)

Supports a
Channel Binding            No                  No

Cryptographic security
status                     None                Medium (***)

Support for non-ASCII
identities (SASLPrep       Yes                 No (?)
or UTF-8)

...

(*) PLAIN solves the security problem by being used under TLS.

(**) This is a consequence of the previous item, but explained from a
different point of view which often comes up in deployment.

(***) There are no published attack against HMAC-MD5 even though the
underlying MD5 function has been attacked.  There are analysis that
suggests HMAC can be used securely even with moderately broken hash
functions. [Reference to Krawczyk's paper]

/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 m7C9UelD013403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 02:30:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C9UeZZ013402; Tue, 12 Aug 2008 02:30:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C9UbXi013394 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 12 Aug 2008 02:30:39 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSqD3-0000HH-Js for [e-mail]; Tue, 12 Aug 2008 09:30:33 +0000
Received: from 212.82.251.163 ([212.82.251.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 09:30:33 +0000
Received: from nobody by 212.82.251.163 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 09:30:33 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Tue, 12 Aug 2008 11:31:20 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 22
Message-ID: <g7rl7f$kdl$[e-mail]>
References:  <[e-mail]>            <[e-mail]>            <[e-mail]>            <g7r2et$50e$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.163
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> I ignored the "without channel bindings" phrases in your =20
> question as neither PLAIN nor CRAM-MD5 provide channel
> bindings.

Good, that is what I meant.  Likely I'm mistaken, but one
point of channel bindings appears to be an answer to the
question "am I talking with the site I wish to talk with"
(as opposed to a MITM).=20

Even if that is an unrelated issue, PLAIN can't be a good
plan when I'm not sure about the other side.=20

The right hand side of a challenge in "Message-ID format"
can be twisted into what I expect by an attacker, it's no
security feature.

I just wondered s/21/17/ months ago why the draft insists
on ignoring the format of the challenge with new MUSTard.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C5ZavP095076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 22:35:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C5ZaA9095075; Mon, 11 Aug 2008 22:35:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from orthanc.ca (gandalf.orthanc.ca [216.40.124.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C5ZYHf095069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 11 Aug 2008 22:35:35 -0700 (MST) (envelope-from [e-mail])
Received: from peregrin.orthanc.ca (peregrin.orthanc.ca [216.40.124.67]) by orthanc.ca (8.14.2/8.14.2) with ESMTP id m7C5ZWKF006561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 22:35:32 -0700 (PDT) (envelope-from [e-mail])
Date: Mon, 11 Aug 2008 22:35:22 -0700 (PDT)
From: Lyndon Nerenberg <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
cc: Frank Ellermann <[e-mail]>, [e-mail]
Subject: Re: Random data
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>            <[e-mail]>            <[e-mail]> <g7r2et$50e$[e-mail]> <[e-mail]>
Organization: The Frobozz Magic Homing Pigeon Company
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Depends on which traits one thinks are desirable.   In general, I would say 
> that CRAM-MD5 offers slightly better security than PLAIN, while PLAIN offers 
> better ability to support external/legacy password stores, proxy-authz, etc.

Where is the peer reviewed analysis of CRAM-MD5 vs. PLAIN that everyone 
alludes to? A simple reference to it in son-of-2195 would solve this 
argument.

--lyndon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C5GemX094096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 22:16:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C5Gem7094095; Mon, 11 Aug 2008 22:16:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C5GcKN094089 for <[e-mail]>; Mon, 11 Aug 2008 22:16:39 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 06:16:37 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
In-Reply-To: <g7r2et$50e$[e-mail]>
Subject: Re: Random data
Date: Mon, 11 Aug 2008 22:16:35 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7r2et$50e$[e-mail]>
X-Mailer: Apple Mail (2.924)
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 11 Aug 2008, at 9:11 PM, Frank Ellermann wrote:

> Is PLAIN over TLS without channel bindings less desirable
> than CRAM-MD5 over TLS without channel bindings ?

Depends on which traits one thinks are desirable.   In general, I  
would say that CRAM-MD5 offers slightly better security than PLAIN,  
while PLAIN offers better ability to support external/legacy password  
stores, proxy-authz, etc.

I don't think either is well suited for general use on the Internet  
without TLS.

(I note that I ignored the "without channel bindings" phrases in your  
question as neither PLAIN nor CRAM-MD5 provide channel bindings.)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C4Ug4f091484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 21:30:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C4UgT2091483; Mon, 11 Aug 2008 21:30:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C4UeD2091476 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 11 Aug 2008 21:30:41 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSlWp-0005ll-Gd for [e-mail]; Tue, 12 Aug 2008 04:30:39 +0000
Received: from 212.82.251.20 ([212.82.251.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 04:30:39 +0000
Received: from nobody by 212.82.251.20 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 04:30:39 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Interoperability
Date:  Tue, 12 Aug 2008 06:31:14 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 27
Message-ID: <g7r3l6$728$[e-mail]>
References:  <[e-mail]><[e-mail]><[e-mail]><g7qd9g$lvi$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.20
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman wrote:

> it is generally advisable to make it clear whether you are
> appealing the process--in this case arguing that the WG did
> not have the consensus Kurt claims it does--or appealing
> the technical decsion--arguing that the WG is wrong.

ACK.  There were some off list messages meanwhile, and I hope
that Pasi now has enough facts to figure out what it's about:

I'm not aware of any interop issues wrt RFC 2195, and I don't
consider CRAM-MD5 as a hopeless case.  I also couldn't say
that DIGEST-MD5 is hopeless, but it is certainly worse than
CRAM-MD5 wrt interoperability.

Kurt asked me to post one point also on the list, here it is:

|>> It is IMHO not posssible to promote CRAM-MD5 on standards
|>> track if its i18n issue is FUBAR.
[...]
| obviously I *disagree* with the premise of this statement,
| it is *not* impossible to add i18n to CRAM-MD5. =20

| Your consensus statement exactly is this *disputed* premise,
| you indirectly say that CRAM-MD5 is a hopeless case. =20

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C4AKAV089952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 21:10:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C4AKlZ089951; Mon, 11 Aug 2008 21:10:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C4AIs2089943 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 11 Aug 2008 21:10:19 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSlD7-00053j-3o for [e-mail]; Tue, 12 Aug 2008 04:10:17 +0000
Received: from 212.82.251.20 ([212.82.251.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 04:10:17 +0000
Received: from nobody by 212.82.251.20 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 04:10:17 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Random data
Date:  Tue, 12 Aug 2008 06:11:02 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 19
Message-ID: <g7r2et$50e$[e-mail]>
References:  <[e-mail]>            <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.20
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> On 14 Mar 2007, at 12:05 PM, Frank Ellermann wrote:

Rather old.  As long as the new MUST causes no procedural
problems I can live with it.  It is against the *concept*
of a Message-ID from my POV, but I can't judge if that is
actually an issue in the context of CRAM-MD5.

I also cannot judge if a Message-ID "nearer" to the idea
of channel-bindings than this new MUST, or how far beside
the point it was when I asked this question 21 months ago.

Maybe something I wrote off-list today hits a SASL point:
Is PLAIN over TLS without channel bindings less desirable
than CRAM-MD5 over TLS without channel bindings ?

 Frank




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C3skNk089032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 20:54:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C3skYw089031; Mon, 11 Aug 2008 20:54:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C3shOW089023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 11 Aug 2008 20:54:45 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSky2-0004WW-HQ for [e-mail]; Tue, 12 Aug 2008 03:54:42 +0000
Received: from 212.82.251.20 ([212.82.251.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 03:54:42 +0000
Received: from nobody by 212.82.251.20 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 12 Aug 2008 03:54:42 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Interoperability
Date:  Tue, 12 Aug 2008 05:55:29 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 28
Message-ID: <g7r1ho$34n$[e-mail]>
References:  <[e-mail]>            <[e-mail]>            <[e-mail]>            <g7qd9g$lvi$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.20
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:
=20
> Your message appears to be a rehash of prior comments.

Just in case, I'm pretty sure that yesterday was the first
time I looked up any details in RFCs 1734, 1731, and 1730.

And of course I'm not sure that my "reconstruction" of the
historical RFC 2195 context is correct.  I recall that one
of the RFC 2195 co-authors supported my *prior* comments
in a similar direction on the general list some years ago:

<http://article.gmane.org/gmane.ietf.general/22272/>
<http://article.gmane.org/gmane.ietf.general/22297/>

> I recall you participating in discussions where
> interoperability problems where discussed.

Likely that was the thread on the general list two years
ago containing the articles linked above.  As noted I'm
not aware of practical CRAM-MD5 interop issues, otherwise
I'd have mentioned such issues in the interop report.

BTW, no new insights from my POV.  The about three times
in the last years I saw questions about CRAM-MD5 it was
about simple "how to" issues, not about interoperability.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C3IYLu087189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 20:18:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C3IYLx087187; Mon, 11 Aug 2008 20:18:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C3IWvx087181 for <[e-mail]>; Mon, 11 Aug 2008 20:18:33 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 04:18:31 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: "Frank Ellermann" <[e-mail]>, [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date: Mon, 11 Aug 2008 20:18:28 -0700
References: <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]> <[e-mail]> <[e-mail]> <g6vnus$mt5$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
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 11 Aug 2008, at 7:52 PM, Kurt Zeilenga wrote:

>>
>> RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII.
>> If implementations do something that is not specified it is their
>> problem.  If they ignored RFC 2277 and didn't pick UTF-8 for their
>> choice of "something" they also own the pieces of whatever breaks.
>
> I see reason why an implementor of RFC 2195 would read RFC 2277, and  
> if they did, why they would take its statements as imparting any  
> requirement upon implementations of any protocol.   RFC 2277  
> discussions requirements upon technical specifications produced by  
> the IETF, not requirements upon implementors of IETF produced  
> technical specifications.

s/see/see no/

Sorry, 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 m7C2r0lm085773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 19:53:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C2r0MZ085772; Mon, 11 Aug 2008 19:53:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C2qmol085763 for <[e-mail]>; Mon, 11 Aug 2008 19:52:54 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SKD6=[e-mail]>; Tue, 12 Aug 2008 03:52:47 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
In-Reply-To: <g6vnus$mt5$[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date: Mon, 11 Aug 2008 19:52:44 -0700
References: <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]> <[e-mail]> <[e-mail]> <g6vnus$mt5$[e-mail]>
X-Mailer: Apple Mail (2.924)
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 1 Aug 2008, at 12:26 PM, Frank Ellermann wrote:

> This is a red herring.  RFC 2026 demands maturity, IMO it does not
> ask "would you do this again exactly as is now, six years later ?".

I would argue that what RFC 2026 demands specifications which  
developers can independently produce interoperable implementations from.

When I said "considered anew", I didn't mean "would we do this again  
exactly as we before".  What I mean was that a document shouldn't get  
a bye from currently in place requirements simply because it was  
originally engineered before those requirements were in place.   And  
while we do now have a "use UTF-8" requirement in IETF protocols, that  
doesn't necessarily mean that non-UTF-8 character data fields in  
fields should be respecified as carrying UTF-8 character data.   There  
are other approaches for providing internationalization in existing  
protocols (such as taken in IDN), and then there is the approach of  
replacing the old protocol with a new protocol that has adequate  
internationalization.

While my discussion above utilizes i18n issues, the I-Ds failure to  
met requirements placed upon it are not believed to be limited to i18n  
issues.

> RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII.
> If implementations do something that is not specified it is their
> problem.  If they ignored RFC 2277 and didn't pick UTF-8 for their
> choice of "something" they also own the pieces of whatever breaks.

I see reason why an implementor of RFC 2195 would read RFC 2277, and  
if they did, why they would take its statements as imparting any  
requirement upon implementations of any protocol.   RFC 2277  
discussions requirements upon technical specifications produced by the  
IETF, not requirements upon implementors of IETF produced technical  
specifications.

> Actually it is now eleven years later, but CRAM-MD5 drafts spent
> five years in SASL deliberations, that is no problem in RFC 2195.

I believe the WG consensus is that there are significant problems with  
RFC 2195.

>
>> It seems inappropriate to keep such a specification on the
>> standards track.
>
> 2026bis is fortunately no deliverable of the SASL WG, what it's
> supposed to deliver is a DS for CRAM-MD5.

That's what it was chartered to delivered.   The WG consensus seems  
not to attempt to met all the requirements for draft standard here.   
One could argue given this, the WG should simply abandon its work to  
date.  However, it seems quite reasonable for the WG to offer what it  
has done to date for publication on the track it finds most suitable.

-- 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 m7C1qahT082957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 18:52:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C1qamb082956; Mon, 11 Aug 2008 18:52:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C1qZm4082949 for <[e-mail]>; Mon, 11 Aug 2008 18:52:35 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 02:52:33 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Frank Ellermann <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Random data (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date: Mon, 11 Aug 2008 18:52:30 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
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 14 Mar 2007, at 12:05 PM, Frank Ellermann wrote:

>
> Tom Yu wrote:
>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-08.txt
> [...]
>> Please review this document, and address feedback to the Working
>> Group mailing list.
>
> Why does it say "MUST NOT interpret the challenge in any way" ?

In reviewing the archives, I see no response to this specific  
question.   I ask that the editor, or other kind individuals, respond  
directly to this question.

Frank, to the extent you desire some change in the document here,  
please offer specific replacement text (stating precisely what OLD you  
want replaced with what NEW).   Thanks, Kurt


> It
> used to be an STD 11 <msg-id> as described in STD 53 (= different
> for each challenge).
>
> "Random data" is NEVER a <msg-id>, it could be the same no matter
> how unlikely that is.  A <msg-id> is supposed to be worldwide unique
> _forever_ (the 2195 use of the term "timestamp" also suggests this).
>
> Frank
>
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C1iLHC082580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 18:44:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C1iLaL082579; Mon, 11 Aug 2008 18:44:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C1iJlU082573 for <[e-mail]>; Mon, 11 Aug 2008 18:44:20 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 02:44:18 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Frank Ellermann <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Security (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date: Mon, 11 Aug 2008 18:44:16 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
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 14 Mar 2007, at 1:11 PM, Frank Ellermann wrote:

>
> | CRAM-MD5 is no longer considered to provide adequate protection.

I believe the WG consensus supports the inclusion of this statement in  
the I-D, as well as the detailed consideration text that follows it.

>
>
> That's not the case, as it depends on the circumstances where
> CRAM-MD5 is used.  E.g. over TLS it could be fine (ignoring the
> issue discussed in a separate thread wrt 2554bis), and CRAM-MD5
> is certainly better than APOP (as stated in 2195) or "LOGIN".
>
> It's also "better" than DIGEST-MD5 where it's easy to implement
> and almost impossible to get it wrong.  Where somebody managed
> to implement 2069 / 2617 / 2831 / 2831bis with their many more
> or less subtle differences CRAM-MD5 still isn't much worse for
> its purpose:  It only has no <cnonce> and no <response-auth>.
>
> That's noted in the 3rd paragraph of the security considerations.
> Readers are able to draw their own conclusions without this
> "executive summary" at the begin.  Besides there is already
> another summary in the intro:
>
> | The mechanism offers inadequate protection against common
> | attacks against application-level protocols (see Section 5)
> | and is prone to interoperability problems (see Section 4).
>
> Section 5 explains why that's not limited to application-
> level protols, therefore this statement could be truncated:
>
> | The mechanism offers inadequate protection against common
> | attacks (see Section 5).
>
> Frank

I believe the WG has considered your input here.   I do not see  
adequate support within the WG to make any of the changes you suggest.

-- 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 m7C1fo1D082461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 18:41:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C1foie082460; Mon, 11 Aug 2008 18:41:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C1fnoR082453 for <[e-mail]>; Mon, 11 Aug 2008 18:41:49 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 02:41:48 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Frank Ellermann <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Limited use (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date: Mon, 11 Aug 2008 18:41:46 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
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 14 Mar 2007, at 12:13 PM, Frank Ellermann wrote:

>
> Tom Yu wrote:
>
>> address feedback to the Working Group mailing list.
>
> | The CRAM-MD5 mechanism is intended to have limited use on the  
> Internet.

I believe WG consensus supports the general statement of applicability.

> That's not the case, as it clearly contradicts what RFC 2195 says.
> It's also in conflict with BCP 46, RFC 2244, RFC 2645, and 2554bis.

I believe the WG has considered your input in this area.

Regards, 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 m7C1UOnt081858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 18:30:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C1UOhJ081857; Mon, 11 Aug 2008 18:30:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C1UM6K081851 for <[e-mail]>; Mon, 11 Aug 2008 18:30:24 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0760941EF; Mon, 11 Aug 2008 21:30:20 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 11 Aug 2008 21:30:19 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Fri, 08 Aug 2008 16:20:53 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Simon" == Simon Josefsson <[e-mail]> writes:
    >> And of course there is the encoded channel bindings (the
    >> b64-cb-data), which I'll understand as soon as I've read up on
    >> channel bindings:-)

    Simon> Possibly it is of no use, and only the channel binding name
    Simon> is needed.  By sending a HMAC blob using the channel
    Simon> bindings as key you may get some other properties, but I'm
    Simon> less certain there is any significant motivation to do
    Simon> this.  I'm not even sure we need to depend on the channel
    Simon> binding vehicle.  The EXTERNAL-CHANNEL mechanism could be
    Simon> renamed to EXTERNAL-TLS and be made specific to refer to
    Simon> the outer TLS channel inside the application protocol, and
    Simon> the client credentials negotiated in that TLS session.
If you send channel bindings, the point would presumably be to
distinguish between two channels of the same type that both exist.  I
think that might be useful.  I don't think you can get any security
properties out of channel bindings without also doing an
authentication at the layer that is exchanging channel bindings.

However channel bindings can be a good name for a channel.  Note that
in some cases the name is not unique.  Also, in some cases the name
must be kept confidential.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C1G0Zd080988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 18:16:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C1G0vA080987; Mon, 11 Aug 2008 18:16:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C1FxuV080979 for <[e-mail]>; Mon, 11 Aug 2008 18:16:00 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AA9F441EF; Mon, 11 Aug 2008 21:15:56 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
Cc: [e-mail]
Subject: Re: Interoperability
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]>
Date: Mon, 11 Aug 2008 21:15:56 -0400
In-Reply-To: <g7qd9g$lvi$[e-mail]> (Frank Ellermann's message of "Tue, 12 Aug 2008 00:09:45 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Frank, when filing an appeal it is generally advisable to make it
clear whether you are appealing the process--in this case arguing that
the WG did not have the consensus Kurt claims it does--or appealing
the technical decsion--arguing that the WG is wrong.

It is also advisable to explain why you think the decision is
wrong--something that I do not believe you have 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 m7C0kDKk079197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 17:46:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C0kDIv079196; Mon, 11 Aug 2008 17:46:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C0kCe3079190 for <[e-mail]>; Mon, 11 Aug 2008 17:46:12 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 01:46:10 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Frank Ellermann <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Interoperability
Date: Mon, 11 Aug 2008 17:46:08 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
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 11 Aug 2008, at 5:28 PM, Kurt Zeilenga wrote:

> As I understand RFC 2277, RFC 2277 state what character set is used  
> for any particular piece of character data used in any protocol.   
> It's a statement of what protocols ought to be capable of, not a  
> statement of default character set/encoding for existing or future  
> protocols.

s/RFC 2277 state/RFC 2277 does NOT state/

Sorry, 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 m7C0SvnV078062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 17:29:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7C0SvvT078061; Mon, 11 Aug 2008 17: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7C0Stqq078054 for <[e-mail]>; Mon, 11 Aug 2008 17:28:56 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.100] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 12 Aug 2008 01:28:53 +0100
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: "Frank Ellermann" <[e-mail]>
In-Reply-To: <g7qd9g$lvi$[e-mail]>
Subject: Re: Interoperability
Date: Mon, 11 Aug 2008 17:28:51 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <g7qd9g$lvi$[e-mail]>
X-Mailer: Apple Mail (2.924)
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 11 Aug 2008, at 3:09 PM, Frank Ellermann wrote:

>
> Kurt Zeilenga wrote:
>
>> I believe there is consensus within the WG that RFC 2195
>> failed to adequately specify how character data inputs,
>> in particular the shared secret, are to be encoded and
>> prepared for input to cryptographic functions

Your message appears to be a rehash of prior comments.  I respond  
mainly to provoke some clarification precisely what you are appealing.

>>
>
> RFC 2195 was written before RFC 2277, the IETF Policy on
> Character Sets and Languages.
>
>
> Above its reference to RFC 822 (STD 11), which uses ASCII,
> RFC 2195 was obviously designed for use with POP3 and IMAP
> as specified in RFC 1731 and 1734 at this time.
>
>
> RFC 2195 and 1734 both intend to be better than APOP, with
> a reference to RFC 1731 in 1734 for some syntax fine print.
>
> RFC 1731 in turn is based on RFC 1730 for the secrets of a
> <userid> and <password> at this time:
>
>   password        ::= astring
>   userid          ::= astring
>
> That boils down to the known concepts of ASCII atoms etc.
> as used everywhere in protocols related to RFC 822 mail.

The WG could have, I guess, chosen to limit the CRAM-MD5 userid and  
password to astrings.  Are you now suggesting the WG now (re)consider  
this?

>
>
> That RFC 1730 itself with its CHAR8 concept is not more
> state of the art is understood, and IMO this needs no WG
> consensus:  The RFCs replacing RFC 822, 1730, and 1734
> are supposed to represent an IETF consensus at the time
> when they were approved, or really soon wrt say 2822upd.
>
>> this has lead to interoperability problems.
>
> I've not heard of interoperabilty problems for RFC 2195
> in the context of its specification.

I recall you participating in discussions where interoperability  
problems where discussed.   In particulars, discussions concerning  
interoperability issued due to RFC 2195 lack of precise specification  
of the character set/encoding/normalization of the CRAM-MD5 password  
word.

> If some implementations allowed non-ASCII, and missed the
> fact that this requires a common charset, and that UTF-8
> is the only candidate as specified in RFC 2277 published
> three months after RFC 2195, then such "interop problems"
> would be entirely the fault of these implementations.

As I understand RFC 2277, RFC 2277 state what character set is used  
for any particular piece of character data used in any protocol.  It's  
a statement of what protocols ought to be capable of, not a statement  
of default character set/encoding for existing or future protocols.

> The crammd5 drafts and the WG Charter tackle this trivial
> issue, RFC 1730 <astring> or similar ASCII limitations are
> obsolete, but fortunately UTF-8 can work "as is" in 8bit
> clean code.

I believe there is significant disagreement that saying "use UTF-8" is  
sufficient to ensure interoperability of character data inputs to  
cryptographic functions.   I note that the WG discussed this various  
issue when revising RFC 2222 and that discussion lead to the following  
statement in RFC 4422 (which replaces RFC 2222):
>> In order to avoid interoperability problems due to differing  
>> normalizations, when a mechanism calls for character data (other  
>> than the authorization identity string) to be used as input to a  
>> cryptographic and/or comparison function, the specification MUST  
>> detail precisely how and where (client or server) the character  
>> data is to be prepared, including all normalizations, for input  
>> into the function to ensure proper operation.

Hence, I believe that consensus is that a "use UTF-8" statement is  
inadequate.   (I note that the crammd5 I-D says "should use UTF-8",  
which weaker than a "use UTF-8" statement".)

>
>
> I'm fine with using SASLprep "everywhere" (incl. CRAM-MD5)
> in SASL,

I guess I don't quite understand what part of my statement you are  
appealing.   Are you arguing for a MUST UTF-8, MUST SASLprep?
> or maybe switch to RFC 5198 "everywhere" when it
> turns out that SASLprep is not implemented.


>
>
>> Your input was considered by the WG, but not found to be
>> compelling.
>
> I appeal that decision.

Are you saying, that in your opinion, that the WG didn't consider your  
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 m7BM95ED069794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 15:09:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BM95fw069793; Mon, 11 Aug 2008 15:09:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BM92r7069778 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 11 Aug 2008 15:09:04 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KSfZS-000843-3v for [e-mail]; Mon, 11 Aug 2008 22:08:58 +0000
Received: from 212.82.251.20 ([212.82.251.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 11 Aug 2008 22:08:58 +0000
Received: from nobody by 212.82.251.20 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Mon, 11 Aug 2008 22:08:58 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: Interoperability
Date:  Tue, 12 Aug 2008 00:09:45 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 59
Message-ID: <g7qd9g$lvi$[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.20
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:
=20
> I believe there is consensus within the WG that RFC 2195
> failed to adequately specify how character data inputs,
> in particular the shared secret, are to be encoded and
> prepared for input to cryptographic functions

RFC 2195 was written before RFC 2277, the IETF Policy on
Character Sets and Languages.

Above its reference to RFC 822 (STD 11), which uses ASCII,
RFC 2195 was obviously designed for use with POP3 and IMAP
as specified in RFC 1731 and 1734 at this time.

RFC 2195 and 1734 both intend to be better than APOP, with
a reference to RFC 1731 in 1734 for some syntax fine print.

RFC 1731 in turn is based on RFC 1730 for the secrets of a
<userid> and <password> at this time:

   password        ::=3D astring
   userid          ::=3D astring

That boils down to the known concepts of ASCII atoms etc.
as used everywhere in protocols related to RFC 822 mail.

That RFC 1730 itself with its CHAR8 concept is not more
state of the art is understood, and IMO this needs no WG
consensus:  The RFCs replacing RFC 822, 1730, and 1734
are supposed to represent an IETF consensus at the time
when they were approved, or really soon wrt say 2822upd.

> this has lead to interoperability problems.

I've not heard of interoperabilty problems for RFC 2195
in the context of its specification.

If some implementations allowed non-ASCII, and missed the
fact that this requires a common charset, and that UTF-8
is the only candidate as specified in RFC 2277 published
three months after RFC 2195, then such "interop problems"
would be entirely the fault of these implementations.

The crammd5 drafts and the WG Charter tackle this trivial
issue, RFC 1730 <astring> or similar ASCII limitations are
obsolete, but fortunately UTF-8 can work "as is" in 8bit
clean code.

I'm fine with using SASLprep "everywhere" (incl. CRAM-MD5)
in SASL, or maybe switch to RFC 5198 "everywhere" when it
turns out that SASLprep is not implemented.

> Your input was considered by the WG, but not found to be
> compelling.

I appeal that decision.  As remedy I propose to issue an
IETF Last Call of the CRAM-MD5 draft on standards track.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BLlgWJ068515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 14:47:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BLlgA4068514; Mon, 11 Aug 2008 14:47:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BLlf8N068508 for <[e-mail]>; Mon, 11 Aug 2008 14:47:42 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6CC9A41EF; Mon, 11 Aug 2008 17:47:39 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: Re: ABNF for the three cases of GS2
References: <[e-mail]> <[e-mail]>
Date: Mon, 11 Aug 2008 17:47:39 -0400
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 11 Aug 2008 16:42:00 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Nicolas> On Mon, Aug 11, 2008 at 05:14:33PM -0400, Sam Hartman
    Nicolas> wrote:
    >> I have put together ABNF for the three cases of GS2.
    >> 
    >> A few notes:
    >> 
    >> * I've punted on the whole OID issue at the beginning of the
    >> client context token, defining a rule oidgunk that we'll need
    >> to figure out.  That may involve negotiation with kitten.

    Nicolas> If Chris doesn't mind the RFC2743 pseudo-ASN.1 OID +
    Nicolas> length header, then let's keep it.  Otherwise let's
    Nicolas> compress it in GS2.

I thought Chris minded the fact that it is a non-constant string with a DER length covering the entire context token.

My preference is to update 2743 to allow the length in that encoding
to cover either the entire token or the oid as defined by the
mechanism spec.

If we cannot make that fly either because of interop problems or
consensus problems to compress in 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 m7BLg3rN068210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 14:42:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BLg3GB068209; Mon, 11 Aug 2008 14:42:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-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 m7BLg23O068203 for <[e-mail]>; Mon, 11 Aug 2008 14:42:03 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7BLg2Q0003812 for <[e-mail]>; Mon, 11 Aug 2008 21:42:02 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 m7BLg2NT038935 for <[e-mail]>; Mon, 11 Aug 2008 15:42:02 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7BLg197015018; Mon, 11 Aug 2008 16:42:01 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7BLg1Wj015017; Mon, 11 Aug 2008 16:42:01 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 11 Aug 2008 16:42:00 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: ABNF for the three cases of GS2
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 11, 2008 at 05:14:33PM -0400, Sam Hartman wrote:
> I have put together ABNF for the three cases of GS2.
> 
> A few notes:
> 
> * I've punted on the whole OID issue at the beginning of the client
>   context token, defining a rule oidgunk that we'll need to figure
>   out.  That may involve negotiation with kitten.

If Chris doesn't mind the RFC2743 pseudo-ASN.1 OID + length header, then
let's keep it.  Otherwise let's compress it in GS2.

> * This assumes that gs2 implementations are required to send the
>   mic/wrap token as soon as possible and that scram implementations
>   are required to be prot_ready when the client final message is sent.

Agreed.

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 m7BLU07d067626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 14:30:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BLU07B067625; Mon, 11 Aug 2008 14:30:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BLTxSJ067619 for <[e-mail]>; Mon, 11 Aug 2008 14:29:59 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7BLTxCq014299 for <[e-mail]>; Mon, 11 Aug 2008 21:29:59 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7BLTx8i032579 for <[e-mail]>; Mon, 11 Aug 2008 15:29:59 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7BLTw5C015001; Mon, 11 Aug 2008 16:29:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7BLTvwV015000; Mon, 11 Aug 2008 16:29:57 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 11 Aug 2008 16:29:57 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: When does scram become prot_ready
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 11, 2008 at 04:04:29PM -0500, Nicolas Williams wrote:
> Technically this can become PROT_READY when message #3 is produced
> (i.e., on the second call to GSS_Init_sec_context()).

Duh, it can become PROT_READY when the server produces its first context
token.  But that gives clients material that they can attack off-line,
so let's not do this.

SCRAM should become PROT_READY when the client produces its second
context token.

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 m7BLPOOu067344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 14:25:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BLPOJ4067343; Mon, 11 Aug 2008 14:25:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BLPN1u067337 for <[e-mail]>; Mon, 11 Aug 2008 14:25:24 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B11F141EF; Mon, 11 Aug 2008 17:25:21 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: Re: When does scram become prot_ready
References: <[e-mail]> <[e-mail]>
Date: Mon, 11 Aug 2008 17:25:21 -0400
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 11 Aug 2008 16:04:29 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


    Nicolas> Technically this can become PROT_READY when message #3 is
    Nicolas> produced (i.e., on the second call to
    Nicolas> GSS_Init_sec_context()).

    Nicolas> Nico --


I actually think it *could* become prot_ready with the second message.
By that point you know all the nonces.
I'm uncomfortable with the security implicatinos of that though.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BLEaDO066581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 14:14:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BLEaqP066580; Mon, 11 Aug 2008 14:14:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BLEZpb066573 for <[e-mail]>; Mon, 11 Aug 2008 14:14:36 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 61F8841EF; Mon, 11 Aug 2008 17:14:33 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: ABNF for the three cases of GS2
Date: Mon, 11 Aug 2008 17:14:33 -0400
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have put together ABNF for the three cases of GS2.

A few notes:

* I've punted on the whole OID issue at the beginning of the client
  context token, defining a rule oidgunk that we'll need to figure
  out.  That may involve negotiation with kitten.

* I'm only providing Grammar for the parts of scram that SASL actually
  uses.  Nico at least believes that the GSS-API mechanism should
  provide sequencing.  I've included enough stuff that a pure SASL
  mechanism would parse and ignore any such usage but have not
  explored it.

* There are two channel binding slots: one used by sasl in
  scram-wrap-c2-inner and one used by non-SASL GSS-API applications in scram-c2-ctx

* Most of the protocol is the same between all three cases.

* This assumes that gs2 implementations are required to send the
  mic/wrap token as soon as possible and that scram implementations
  are required to be prot_ready when the client final message is sent.

My current preference is a moderate preference for case 2.  I might
like case 3 better if someone suggested a better way to determine the
end of the non-context part.

; Some rules used by most of the grammars:
gs2-to-be-protected = qop ["," maxbuf] ["," cbqop "," channelbinding] 
    ["," authzid] ["," 1*extension]
qop = "qop=" qopvalue *( "+" qopvalue)
qopvalue = "none" ; no security layer
    / "integ" ; integrity protection
    / "conf" ; confidentiality protection
    / "cbgood" ; channel binding validated (server to client)
maxbuf = "maxbuf=" digits
cbqop = "cbqop=" qopvalue *( "+" qopvalue); QOPs that can be used if channel binding succeeds
channelbinding = "cb=" base64
authzid = "authzid=" base64
extension = alphanum "=" *extensionchar
extensionchar = value-char
value-safe-char = %20-2B / %2D-3C / %3E-7E /
		  UTF8-2 / UTF-3 / UTF8-4
		  ;; UTF8-char except CTL, "=", and ",".

value-char      = value-safe-char / "="

; The scram message parts that are constant across all three cases
scram-c1-ctx = oidgunk username "," hash-list "," nonce
; oidgunk needs to be discussed on the list
scram-s1-ctx = nonce "," hash-list "," salt "," iteration-count
scram-c2-ctx = nonce "," gss-channel-binding "," proof
; gss-channel-binding is used  for non-SASL GSS-API
; but not for sasl apps

scram-s2-ctx = verifier

; The content that gets wrapped is also constant across all three cases
; We don't consider it desirable that scram have a security layer.
; However it seems like scram is going to be enough of a gss-api mechanism
; that it will end up having a well-defined security layer. 
; A SCRAM implementation with a full GSS-API  implementation MAY end up using 
; security layers and as such all SCRAM implementations need to parse qops  and
; maxbuf specifications. However pure SASL implementation can send a limited set  of responses
; and need not actually implement security layers
; The following rules demonstrate what will be carried between  two sasl-
; only scram  implementations that do not support security layers.
; the following two rules are the scram wrap from client to server and server to client
saslscram-wrap-c2-inner = "qop=none" ["," "cbqop=none" "," channelbinding] 
    ["," authzid] [ "," 1*extension]
saslscram-wrap-s2-inner = "qop=none" [ "+cbgood" ] [ "," 1*extension]
; and here are rules for what implementations must parse
scram-wrap-c2-inner = qop ["," maxbuf ] ["," cbqop "," channelbinding] ["," authzid] 
    ["," 1*extension]
; The following rule could probably be simplified  as it's not clear maxbuf
; will ever appear in the s2 message unless you have two gs2-implementations 
; talking that have actually decided to use security layers
scram-wrap-s2-inner = qop ["," maxbuf] ["," 1*extension]


; Grammar: case 1 two base 64 tokens

gs2-message = gs2-context "," gs2-wrap
gs2-context = base64 ; completely defined by the mechanism
gs2-wrap = base64 ; processed by the mechanism but including the data from gs2-wrap-inner
gs2-wrap-inner = gs2-to-be-protected
scram-wrap = "mic="base64 ["," 1*extension] "," "d=" *octet ; MIC and integrity protected data
; So, that would make the SCRAM c2 message look like:
scram-c2-wrap = "mic=" base64 [ "," 1*extension] ",d=" scram-wrap-c2-inner
scram-s2-wrap = "mic=" base64 ["," 1*extension] ",d=" scram-wrap-s2-inner
; So, the client sends base64(scram-c1-ctx):null
; the server sends base64(scram-s1-ctx):nothing
; the client sends base64(scram-c2-ctx):base64(scram-c2-wrap)
; the server sends base64(scram-s2-ctx):base64(scram-s2-wrap)

; Grammar 2: Escaping
; null null encodes null
; null "," separates the context from wrap token
; Feel free to use a different escaping mechanism
escape-char = %x01-ff / (%x00 %x00)
escaped = 1*escape-char
delim = %x00 ","
gs2-message = gs2-ctx delim gs2-wrap
gs2-ctx = escaped
gs2-wrap = escaped
; It happens that the scram messages below conform to escaped
scram-wrap-part = "mic=" base64 ["," 1*extension] ",d="
scram-wrap = scram-wrap-part escaped

scram-c1 = scram-c1-ctx delim 
scram-s1 = scram-s1-ctx delim
scram-c2 = scram-c2-ctx delim scram-wrap-part scram-wrap-c2-inner
scram-s2 = scram-s2-ctx delim scram-wrap-part scram-wrap-s2-inner

; Grammar 3: mic and base64
; In this case we assume that scram-mic is a fixed-length binary hmac followed by extra stuff 
; used by GSS-API but not SASL for sequencing and replay
gs2-message = [gs2-mic gs2-stuff  ","] "ctx="gs2-ctx
; Note that determining where the end of the MIC is a bit tricky; it extends to
; but does not include the final comma in gs2-stuff. You don't know you are at
; the end until you read ctx
gs2-mic = "mic=" base64 "," ; base64 of gss_getmic of gs2-stuff
gs2-stuff = gs2-to-be-protected
gs2-ctx = 1*octet
scram-c1 = "ctx"= scram-c1-ctx
scram-s1 = "ctx"= scram-s1-ctx 
scram-c2 = gs2-mic scram-wrap-c2-inner ",ctx=" scram-c2-ctx
scram-s2 = gs2-mic scram-wrap-s2-inner ",ctx=" scram-s2-ctx



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BL4WD7065888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 14:04:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BL4W74065887; Mon, 11 Aug 2008 14:04:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BL4VHY065878 for <[e-mail]>; Mon, 11 Aug 2008 14:04:32 -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 m7BL4Vfe013680 for <[e-mail]>; Mon, 11 Aug 2008 21:04: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 m7BL4VBT019797 for <[e-mail]>; Mon, 11 Aug 2008 15:04:31 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7BL4Ux9014981; Mon, 11 Aug 2008 16:04:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7BL4TEx014980; Mon, 11 Aug 2008 16:04:29 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 11 Aug 2008 16:04:29 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: When does scram become prot_ready
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Aug 11, 2008 at 04:18:22PM -0400, Sam Hartman wrote:
> I'm assuming that scram does not become prot_ready until the client
> final message. Technically the spec could be written so that scram
> becomes prot_ready on the server when the server produces its first
> message.  I have not thought through the implications of doing
> that--in particular whether it opens up any new opportunities for
> attacks.
> 
> It seems quite clear to me that the scram spec must say when it
> becomes prot_ready for there to be a single gs encoding.  If we decide
> that it becomes prot_ready earlier than the client final message, then
> the ABNF I will be sending later needs to be updated.

In the ABNF I wrote a while back there were four messages as follows
(ignoring GS2 parts):

1: client->server: username, hash-alg-list, nonce
2: server->client: nonce, hash-alg, salt, iteration-count
3: client->server: client-proof
4: server->client: server-proof

Where the "proofs" are some function of the selected hash function,
nonces, username, salt, shared password, iteration count, direction
flag.

Technically this can become PROT_READY when message #3 is produced
(i.e., on the second call to GSS_Init_sec_context()).

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 m7BKIQxQ062633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 13:18:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BKIQVX062632; Mon, 11 Aug 2008 13:18:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BKIPGF062624 for <[e-mail]>; Mon, 11 Aug 2008 13:18:26 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A3B0C41EF; Mon, 11 Aug 2008 16:18:22 -0400 (EDT)
To: [e-mail]
Subject: When does scram become prot_ready
From: Sam Hartman <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 11 Aug 2008 16:18:22 -0400 (EDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm assuming that scram does not become prot_ready until the client
final message. Technically the spec could be written so that scram
becomes prot_ready on the server when the server produces its first
message.  I have not thought through the implications of doing
that--in particular whether it opens up any new opportunities for
attacks.

It seems quite clear to me that the scram spec must say when it
becomes prot_ready for there to be a single gs encoding.  If we decide
that it becomes prot_ready earlier than the client final message, then
the ABNF I will be sending later needs to be updated.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BIdWDQ054910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 11:39:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BIdWG7054909; Mon, 11 Aug 2008 11:39:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BIdVGF054899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 11 Aug 2008 11:39:31 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7BIdTXl056518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Aug 2008 18:39:30 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Frank Ellermann <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Interoperability (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date: Mon, 11 Aug 2008 11:36:38 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Aug 11, 2008, at 11:15 AM, Kurt Zeilenga wrote:

> I believe there is consensus within the WG that RFC 2195 failed to  
> adequately specify how character data inputs, in particular the  
> shared secret, are to be encoded and prepared for input to  
> cryptographic functions and this has lead to interoperability  
> problems.

I should add here:

I also believe there is consensus within the WG that draft-ietf-sasl- 
crammd5, while significantly better in this area (given the UTF-8 and  
SASLprep SHOULDs), it also fails to be precise enough to ensure  
interoperability between independent deployers of the mechanism.

> Your input was considered by the WG, but not found to be compelling.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BIFwaF052944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 11:16:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BIFw32052943; Mon, 11 Aug 2008 11:15:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BIFqox052935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 11 Aug 2008 11:15:57 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m7BIFoj7052748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Aug 2008 18:15:51 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Frank Ellermann <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: Interoperability (was: WG Last Call: draft-ietf-sasl-crammd5-08.txt)
Date: Mon, 11 Aug 2008 11:15:50 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe there is consensus within the WG that RFC 2195 failed to  
adequately specify how character data inputs, in particular the shared  
secret, are to be encoded and prepared for input to cryptographic  
functions and this has lead to interoperability problems.  Your input  
was considered by the WG, but not found to be compelling.

-- Kurt

On Mar 14, 2007, at 12:40 PM, Frank Ellermann wrote:

>
>> address feedback to the Working Group mailing list.
>
> | prone to interoperability problems (see Section 4).
>
> If folks used their own kludges to negotiate charsets out of band
> it's their problem, not a problem in 2195.  The RFC 822 <msg-id>
> in the challenge is clearly ASCII.
>
> RFC 2277 published one year after 2095 clearly mandates to use
> UTF-8.  Alexey proposed to add a "SHOULD UTF-8" somewhere, IMO a
> "MUST" is clearer.
>
> The only "interoperability problem" left will be to use SASLprep,
> and that solves an inherent interoperability problem for Unicode.
>
> RFC 4616 also doesn't spread FUD about alleged "interoperability
> problems" wrt SASLprep, so I don't see why that should be needed
> here (in chapter 1).
>
> Frank
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7B6FWwd096405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 23:15:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7B6FWmd096404; Sun, 10 Aug 2008 23:15:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7B6FSIj096398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 10 Aug 2008 23:15:31 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1KSQgh-0003iN-3f; Mon, 11 Aug 2008 08:15:27 +0200
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.67) (envelope-from <[e-mail]>) id 1KSQgg-0007Qd-Ts; Mon, 11 Aug 2008 08:15:27 +0200
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1KSQgc-00071a-Hu; Mon, 11 Aug 2008 08:15:22 +0200
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 11 Aug 2008 08:15:22 +0200
To: Chris Newman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
In-Reply-To: <367C9F0308E8D9FAD1C0EE1D@446E7922C82D299DB29D899F>
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <367C9F0308E8D9FAD1C0EE1D@446E7922C82D299DB29D899F>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 3793195D9FCDB3736CA0076ED40D8C9A4E53DBA7
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 951 max/h 8 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman writes:
> So I would support creation of an EXTERNAL-TLS mechanism.  Although it
> would be identical to EXTERNAL on-the-wire, I understand the semantic
> difference is valuable.

Yes...

> For transition purposes, I'd say a server
> that advertises EXTERNAL-TLS SHOULD also advertise EXTERNAL.

_During_ transition from EXTERNAL, yes.  Afterwards, if it is
a real problem that users use EXTERNAL and get the wrong channel,
the admin may want to turn off that option.

However if it isn't a problem, one might want to stay with EXTERNAL.
When it works, it's simpler.  And if a client gets yet another user
option to tweak, that doesn't necessarily mean clients users will
tweak it right.  They might e.g. copy some config which did get it
right, and then modify just what kind of channel he actually gets
without also replacing EXTERNAL-TLS with EXTERNAL-something-else.

> I don't support creation of a replacement for EXTERNAL that has a
> sub-negotiation to identify which external context passed client
> credentials -- I think that's a case where sub-negotiations should be
> avoided.

Note that a separate channel field can be useful because the client
can pass a value which SASL does not implement.  E.g. a protocol
implementation like OpenLDAP which can use Unix domain sockets' peer ID:
That way it does not depend on the SASL implementation to implement an
EXTERNAL-UNIX-SOCKET mechanism.  Instead, the LDAP client could pass
"UNIX-SOCKET" through SASL/EXTERNAL-CHANNEL which would pass it on to
the LDAP server.

So - of the two real-life use cases I've encountered, EXTERNAL-TLS
covers half of them.  How to implement the other (EXTERNAL-UNIX-SOCKET)
is OS-dependent.  Might be unsuitable for RFCification, since it
may need to keep up with whatever various OSes come up with.

On the third hand, it does looks easier to deal with EXTERNAL-TLS than
EXTERNAL-CHANNEL("TLS").  Maybe there could be extensible mechanism
names: Reserve all mechanisms named EXTERNAL-X-* for the protocol which
uses SASL.  Include a hook in the SASL library on which the protocol
implementation can hang its own EXTERNAL-X-UNIX-SOCKET implementation.

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7B3DBDW087204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 20:13:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7B3DBDx087203; Sun, 10 Aug 2008 20:13:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 m7B3D9gl087197 for <[e-mail]>; Sun, 10 Aug 2008 20:13:10 -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 m7B3D9oW006692 for <[e-mail]>; Mon, 11 Aug 2008 03:13:09 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7B3D8Xx010659 for <[e-mail]>; Sun, 10 Aug 2008 21:13:08 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7B3D8SB014263; Sun, 10 Aug 2008 22:13:08 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7B3D7Zn014262; Sun, 10 Aug 2008 22:13:07 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sun, 10 Aug 2008 22:13:07 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: GS2 Encoding: To Escape or Base64
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]> <CC873BCBA200669DAD719805@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun, Aug 10, 2008 at 12:47:58PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > Oh, you're proposing that GS2 base64 encode the MIC token.  That works
> > for me.
> 
> How is the MIC token delimited from the context token in GS2?  With a
> non-base64-alphabetic character such as SP?  That could work.

That's what I gathered.  So GS2 messages would look like several
all-text fields (maxbuf, min layers, max layers, layers_if_cb, MIC
token) and one binary token following the text (GSS context token).
SASL prepends a length field, thus there's no ambiguity.

I like this, a lot.

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 m7B39xXv086936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 20:09:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7B39wHk086935; Sun, 10 Aug 2008 20:09:58 -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 m7B39g1M086927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Sun, 10 Aug 2008 20:09:43 -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 m7B39gQq029756 for <[e-mail]>; Mon, 11 Aug 2008 03:09: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 m7B39goB009178 for <[e-mail]>; Sun, 10 Aug 2008 21:09:42 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7B39fK8014255; Sun, 10 Aug 2008 22:09:41 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7B39U4Z014254; Sun, 10 Aug 2008 22:09:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sun, 10 Aug 2008 22:09:30 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <367C9F0308E8D9FAD1C0EE1D@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 Sun, Aug 10, 2008 at 12:51:58PM +0200, Simon Josefsson wrote:
> Chris Newman <[e-mail]> writes:
> > I don't support creation of a replacement for EXTERNAL that has a
> > sub-negotiation to identify which external context passed client
> > credentials -- I think that's a case where sub-negotiations should be
> > avoided.
> 
> I'm starting to agree with this.  The negotiation can be done using the
> SASL mechanism name (EXTERNAL-TLS, EXTERNAL-IPSEC, etc) instead of
> inside the mechanism itself.  This lets the specification discuss things
> that are TLS-specific without violating the abstraction.

+1



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7AArH7c036974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 03:53:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7AArHo6036973; Sun, 10 Aug 2008 03:53:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 m7AArEID036895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 10 Aug 2008 03:53:16 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KS8Wl-0001gl-9C; Sun, 10 Aug 2008 12:51:59 +0200
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <367C9F0308E8D9FAD1C0EE1D@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080810:[e-mail]::i9qHRWTFW6EjJai3:9Iic
X-Hashcash: 1:22:080810:[e-mail]::Xuz4PDRU4OBsNIx/:iFC+
Date: Sun, 10 Aug 2008 12:51:58 +0200
In-Reply-To: <367C9F0308E8D9FAD1C0EE1D@446E7922C82D299DB29D899F> (Chris Newman's message of "Fri, 08 Aug 2008 14:44:41 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> So the key specification difference between "EXTERNAL" and
> "EXTERNAL-TLS" is that a client MUST NOT negotiate EXTERNAL-TLS unless
> client credentials were passed at the TLS layer and the server cert
> was successfully verified (the spec should include an example for this
> case).  And the server MUST NOT advertise EXTERNAL-TLS unless TLS
> client credentials were successfully negotiated at the TLS layer.

This matches my intentions.

> So I would support creation of an EXTERNAL-TLS mechanism.  Although it
> would be identical to EXTERNAL on-the-wire, I understand the semantic
> difference is valuable.  For transition purposes, I'd say a server
> that advertises EXTERNAL-TLS SHOULD also advertise EXTERNAL.

Works fine.

> I don't support creation of a replacement for EXTERNAL that has a
> sub-negotiation to identify which external context passed client
> credentials -- I think that's a case where sub-negotiations should be
> avoided.

I'm starting to agree with this.  The negotiation can be done using the
SASL mechanism name (EXTERNAL-TLS, EXTERNAL-IPSEC, etc) instead of
inside the mechanism itself.  This lets the specification discuss things
that are TLS-specific without violating the abstraction.

/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 m7AAnQVv036740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Aug 2008 03:49:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7AAnQj9036739; Sun, 10 Aug 2008 03:49: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 m7AAnMVi036645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 10 Aug 2008 03:49:25 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KS8Sw-0001gf-3v; Sun, 10 Aug 2008 12:48:03 +0200
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: GS2 Encoding: To Escape or Base64
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]> <CC873BCBA200669DAD719805@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080810:[e-mail]::REiLHGytn0aTCD4v:Q14
X-Hashcash: 1:22:080810:[e-mail]::b5rNWfooJHL2mGK+:GX2h
X-Hashcash: 1:22:080810:[e-mail]::zhBqk1dKUkACMgGd:Abwk
Date: Sun, 10 Aug 2008 12:47:58 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Fri, 8 Aug 2008 11:00:45 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Fri, Aug 08, 2008 at 11:33:31AM -0400, Sam Hartman wrote:
>>     Nicolas> I don't see how that works.  MIC tokens are typically
>>     Nicolas> fixed-sized, but there's no way to know a priori what
>>     Nicolas> that size will be, so we still have two abritriray-size
>>     Nicolas> binary blobs in one message.
>> 
>> GS2 base64 encodes the MIC token.  SCRAM's GSS-API mechanism uses a
>> binary MIC token.  GS2 does not base64 encode the context
>> token. SCRAM's mechanism uses an ASCII context token.
>
> Oh, you're proposing that GS2 base64 encode the MIC token.  That works
> for me.

How is the MIC token delimited from the context token in GS2?  With a
non-base64-alphabetic character such as SP?  That could work.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Liofo017447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 14:44:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78Liowj017446; Fri, 8 Aug 2008 14:44:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Liim1017436 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 8 Aug 2008 14:44:45 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m78Lih46022299 for <[e-mail]>; Fri, 8 Aug 2008 14:44:44 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 08 Aug 2008 14:44:43 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Fri, 08 Aug 2008 14:44:43 -0700 (PDT)
Date: Fri, 08 Aug 2008 14:44:41 -0700
From: Chris Newman <[e-mail]>
Subject: Re: EXTERNAL-CHANNEL
In-reply-to: <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Message-id: <367C9F0308E8D9FAD1C0EE1D@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

EXTERNAL as specified is 100% fine as long as mutual authentication is not 
required.  If the client sees EXTERNAL, it just uses it and everything 
works.

But if mutual authentication is required, then EXTERNAL is problematic.  A 
client has to verify that the mutual authentication has occurred at the 
correct layer prior to using EXTERNAL and passing possibly sensitive data 
to the server.

So the key specification difference between "EXTERNAL" and "EXTERNAL-TLS" 
is that a client MUST NOT negotiate EXTERNAL-TLS unless client credentials 
were passed at the TLS layer and the server cert was successfully verified 
(the spec should include an example for this case).  And the server MUST 
NOT advertise EXTERNAL-TLS unless TLS client credentials were successfully 
negotiated at the TLS layer.

So I would support creation of an EXTERNAL-TLS mechanism.  Although it 
would be identical to EXTERNAL on-the-wire, I understand the semantic 
difference is valuable.  For transition purposes, I'd say a server that 
advertises EXTERNAL-TLS SHOULD also advertise EXTERNAL.

I don't support creation of a replacement for EXTERNAL that has a 
sub-negotiation to identify which external context passed client 
credentials -- I think that's a case where sub-negotiations should be 
avoided.

		- 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 m78G117m091898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 09:01:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78G11CJ091897; Fri, 8 Aug 2008 09:01:01 -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 m78G0sUA091872 for <[e-mail]>; Fri, 8 Aug 2008 09:01:00 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m78G0r1Y020783 for <[e-mail]>; Fri, 8 Aug 2008 16:00:53 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 m78G0rBa053550 for <[e-mail]>; Fri, 8 Aug 2008 10:00:53 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m78G0naK013111; Fri, 8 Aug 2008 11:00:49 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m78G0k4J013110; Fri, 8 Aug 2008 11:00:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 8 Aug 2008 11:00:45 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail], Simon Josefsson <[e-mail]>
Subject: Re: GS2 Encoding: To Escape or Base64
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail], Simon Josefsson <[e-mail]>
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]> <CC873BCBA200669DAD719805@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Aug 08, 2008 at 11:33:31AM -0400, Sam Hartman wrote:
>     Nicolas> I don't see how that works.  MIC tokens are typically
>     Nicolas> fixed-sized, but there's no way to know a priori what
>     Nicolas> that size will be, so we still have two abritriray-size
>     Nicolas> binary blobs in one message.
> 
> GS2 base64 encodes the MIC token.  SCRAM's GSS-API mechanism uses a
> binary MIC token.  GS2 does not base64 encode the context
> token. SCRAM's mechanism uses an ASCII context token.

Oh, you're proposing that GS2 base64 encode the MIC token.  That works
for me.

> I think this third approach may be playing fast and loose with the
> layers a bit much.

Not any more than any of the other solutions.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78FXi00090003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 08:33:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78FXiIT090002; Fri, 8 Aug 2008 08:33:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78FXgp7089996 for <[e-mail]>; Fri, 8 Aug 2008 08:33:43 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0351642B1; Fri,  8 Aug 2008 11:33:31 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail], Simon Josefsson <[e-mail]>
Subject: Re: GS2 Encoding: To Escape or Base64
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]> <CC873BCBA200669DAD719805@446E7922C82D299DB29D899F> <[e-mail]>
Date: Fri, 08 Aug 2008 11:33:31 -0400
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Thu, 7 Aug 2008 20:01:14 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Nicolas> On Thu, Aug 07, 2008 at 05:03:50PM -0700, Chris Newman
    Nicolas> wrote:
    >> --On August 7, 2008 10:54:59 -0400 Sam Hartman
    >> <[e-mail]>
    >> wrote:
    >> >There may be a third approach that involves using gss_getmic
    >> rather >than gss_wrap (thus giving GS2 a bit more control of
    >> layout) where the >MIC is base64 and the context token if
    >> present goes at the end of the >message.  That might actually
    >> work well for SCRAM, although it's >fairly odd to have the
    >> context token (which you process first) go at >the end of the
    >> message.
    >> 
    >> That sounds even better, if the GS2 folks are willing.

    Nicolas> I don't see how that works.  MIC tokens are typically
    Nicolas> fixed-sized, but there's no way to know a priori what
    Nicolas> that size will be, so we still have two abritriray-size
    Nicolas> binary blobs in one message.

GS2 base64 encodes the MIC token.  SCRAM's GSS-API mechanism uses a
binary MIC token.  GS2 does not base64 encode the context
token. SCRAM's mechanism uses an ASCII context token.

The over-the-wire-result is that GS2-SCRAM has a base64 blob for the
MIC (encoded by GS2) and a ascii context token.  The whole result is
ASCII.  This would mean that Kerberos would have binary context tokens
and a base64 MIC token as part of GS2.  It would also mean that
GSS-SCRAM (non-SASL) would have ASCII context tokens and binary MIC
tokens.

I think this third approach may be playing fast and loose with the
layers a bit much.

I think I can put together ABNF for the three approaches next week
provided that work does not suddenly consume my time.  However the
energy I can dedicate to this will go down at some point: currently my IETF work is unfunded.


--Sam



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78EL3bb084310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 07:21:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78EL3I2084309; Fri, 8 Aug 2008 07:21: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 m78EL1d8084301 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 8 Aug 2008 07:21:03 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KRSpq-0000kC-7K; Fri, 08 Aug 2008 16:20:56 +0200
From: Simon Josefsson <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080808:[e-mail]::7OXvuAtKkyE/RffU:G12b
X-Hashcash: 1:22:080808:[e-mail]::aPIJlJaDC+yD4B+9:Lr6v
X-Hashcash: 1:22:080808:[e-mail]::lyccMa3UMKZsT8mI:M1u4
X-Hashcash: 1:22:080808:[e-mail]::z6GlwlgtsVDJ7+sJ:04RIu
Date: Fri, 08 Aug 2008 16:20:53 +0200
In-Reply-To: <[e-mail]> (Hallvard B. Furuseth's message of "Fri, 8 Aug 2008 15:59:16 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>> Furthermore, the server has no way of knowing whether the client
>> intended that TLS or something else should be used.
>
> Stated that strongly, this is a bit of a strawman.  Unless the server
> is set up for specific clients, it can't know what clients and their
> users intend in any case.

That is the flaw I try to correct with EXTERNAL-CHANNEL.  With
EXTERNAL-CHANNEL, the server can know what the client intends.

> Anyway, it's not that EXTERNAL is perfect, I just think this discussion
> is stating its problems somewhat misleadingly and too strongly.
> Also I have no idea how much of a real-life problem EXTERNAL-CHANNEL
> solves, and how much of it is theoretical?

I'd like to find out that as well. ;)

In my experience, EXTERNAL is under-utilized in the real-world for TLS
client credentials.  People appear to avoid EXTERNAL because its
specification says that it requires some out-of-band negotiation.

Whether this is problem with the wording of the EXTERNAL specification,
or a real technical problem in that it only transfer an authorization
identity, that is something I'd like to find out.

> As I see it, in this respect EXTERNAL-CHANNEL can be useful to:
> - pick the right channel of several available alternatives,
> - stop servers from being "too clever" - e.g. ensure authentication
>   fails rather than pick a channel the user or client author didn't
>   even know about,
> - catch user/client errors.

The latter two are the use cases I believe are most realistic.

> And of course there is the encoded channel bindings (the b64-cb-data),
> which I'll understand as soon as I've read up on channel bindings:-)

Possibly it is of no use, and only the channel binding name is needed.
By sending a HMAC blob using the channel bindings as key you may get
some other properties, but I'm less certain there is any significant
motivation to do this.  I'm not even sure we need to depend on the
channel binding vehicle.  The EXTERNAL-CHANNEL mechanism could be
renamed to EXTERNAL-TLS and be made specific to refer to the outer TLS
channel inside the application protocol, and the client credentials
negotiated in that TLS session.

/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 m78DxQfb082922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 06:59:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78DxQe5082921; Fri, 8 Aug 2008 06:59:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78DxNiv082912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 8 Aug 2008 06:59:25 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1KRSUx-0001FO-PS; Fri, 08 Aug 2008 15:59:19 +0200
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx4.uio.no with esmtp  (Exim 4.67) (envelope-from <[e-mail]>) id 1KRSUx-0002v8-IQ; Fri, 08 Aug 2008 15:59:19 +0200
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1KRSUu-0007XR-Pa; Fri, 08 Aug 2008 15:59:16 +0200
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 8 Aug 2008 15:59:16 +0200
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 21.4.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: EBB858B53D7BFF6B1BF230B59609C0914D214B54
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 949 max/h 8 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
>Alexey Melnikov <[e-mail]> writes:
>> Simon Josefsson wrote:
>>> [RFC 2595 and RFC 3501 do] not mean that EXTERNAL needs to use the
>>> TLS channel's credentials.
>>
>> Indeed. The client has no way of knowing for sure if TLS information
>> is going to be used by the server end.

Not so.  SASL by itself cannot know that.  But the client or its user
can know if if it knows how the server picks the channel.  And that the
connection only has one reasonable channel for the server to pick.

> Furthermore, the server has no way of knowing whether the client
> intended that TLS or something else should be used.

Stated that strongly, this is a bit of a strawman.  Unless the server
is set up for specific clients, it can't know what clients and their
users intend in any case.  Whatever a client is doing, it might be buggy
or the user might be clueless.  Servers just have to do what the clients
tell them, after catching what errors they can and bother to catch.


Anyway, it's not that EXTERNAL is perfect, I just think this discussion
is stating its problems somewhat misleadingly and too strongly.
Also I have no idea how much of a real-life problem EXTERNAL-CHANNEL
solves, and how much of it is theoretical?

As I see it, in this respect EXTERNAL-CHANNEL can be useful to:
- pick the right channel of several available alternatives,
- stop servers from being "too clever" - e.g. ensure authentication
  fails rather than pick a channel the user or client author didn't
  even know about,
- catch user/client errors.

And of course there is the encoded channel bindings (the b64-cb-data),
which I'll understand as soon as I've read up on channel bindings:-)

-- 
Hallvard



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78CfHBn075499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 05:41:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78CfHnW075497; Fri, 8 Aug 2008 05:41:17 -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 m78CfAEJ075454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 8 Aug 2008 05:41:16 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KRRHG-0001J8-2r; Fri, 08 Aug 2008 14:41:07 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080808:[e-mail]::+l7GRnRt308/HcEa:0eBu
X-Hashcash: 1:22:080808:[e-mail]::ZKxPCjGh0Dx4325K:Lk+c
X-Hashcash: 1:22:080808:[e-mail]::+99mppZcbVU+bASo:PkzK
Date: Fri, 08 Aug 2008 14:41:05 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Fri, 08 Aug 2008 12:12:19 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>Chris Newman <[e-mail]> writes:
>>  
>>
>>>--On August 7, 2008 14:56:51 +0200 Simon Josefsson
>>><[e-mail]> wrote:
>>>    
>>>
>>>>Chris Newman <[e-mail]> writes:
>>>>      
>>>>
>>>>>While I don't see the utility of making the channel for which EXTERNAL
>>>>>applies explicit, I don't object to that either.  However, EXTERNAL
>>>>>has been widely used for TLS client certificates.
>>>>>        
>>>>>
>>>>My perception is different: few if any MUAs I've used that supports TLS
>>>>client certificates offer the EXTERNAL SASL mechanism for
>>>>authentication.  The EXTERNAL specification says that the channel to use
>>>>is to be negotiated out-of-band, which makes interoperable use of
>>>>EXTERNAL difficult.
>>>>
>>>>I agree that EXTERNAL sometimes is used for TLS client certificates, but
>>>>in my experience that only happens in small environments where the
>>>>administrator communicate this knowledge via some special channel.
>>>>      
>>>>
>>>RFC 2595 compliant clients (both POP and IMAP) will use EXTERNAL with
>>>STARTTLS and client certificates.  RFC 3501 IMAP clients also have to
>>>use EXTERNAL with STARTTLS.  These specifications are not ambiguous on
>>>the topic.
>>>    
>>>
>>The EXTERNAL specification is not clear that the TLS channel is the
>>intended channel, though, quoting RFC 4422:
>>
>>   The EXTERNAL mechanism allows a client to request the server to use
>>   credentials established by means external to the mechanism to
>>   authenticate the client.  The external means may be, for instance, IP
>>   Security [RFC4301] or TLS [RFC4346] services.  In absence of some a
>>   priori agreement between the client and the server, the client cannot
>>   make any assumption as to what external means the server has used to
>>   obtain the client's credentials, nor make an assumption as to the
>>   form of credentials.  For example, the client cannot assume that the
>>   server will use the credentials the client has established via TLS.
>>
>>RFC 2595 and RFC 3501 says that implementations MAY use EXTERNAL with
>>TLS client certificates.  That is correct, but it does not mean that
>>EXTERNAL needs to use the TLS channel's credentials.
>>
> Indeed. The client has no way of knowing for sure if TLS information
> is going to be used by the server end.

Furthermore, the server has no way of knowing whether the client
intended that TLS or something else should be used.

>>In my perception,
>>this ambiguity is the primary reason why EXTERNAL doesn't work well for
>>TLS client certificate re-use.
>>
>>I agree that it would be simpler to revise the EXTERNAL specification to
>>say that it is intended to re-use TLS credentials, similar to how we
>>have revised GSSAPI to mean Kerberos V5.  I'm not convinced it is
>>possible to revise EXTERNAL in this way though, maybe someone is using
>>EXTERNAL to refer to an external SSH connection or similar?
>>
> OpenLDAP uses EXTERNAL when running over a Unix domain socket with no
> TLS. It will use identity from the OS in such cases.

If so, re-vising EXTERNAL to mean TLS credentials appears to not work
well.

>>I would prefer to revise EXTERNAL in this way compared to invent a new mechanism
>>though.  Is this a way forward that others find acceptable?
>>  
>>
> IMHO, SASL EXTERNAL as written is underspecified. I would prefer to
> write a separate mechanism which is unambiguous.

The question is whether the mechanism can/should be TLS-specific, or if
there is any point in re-using the channel binding mechanism which I did
in an attempt to make it more generic.

I initially thought the channel binding approach would be more generic
and make it more easy to re-use for various different channels, but I'm
beginning to doubt it is the best approach.  It may be adding too much
complexity for too little gain.

A mechanism EXTERNAL-TLS would allow the specification to be able to say
more useful things that apply only for TLS.  Mechanism such as
EXTERNAL-IPSEC or EXTERNAL-PPP or whatever could be specified if there
is interest.

/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 m78BCX1j067597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 04:12:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78BCXWX067596; Fri, 8 Aug 2008 04:12:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78BCVKp067583 for <[e-mail]>; Fri, 8 Aug 2008 04:12:32 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.142] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 8 Aug 2008 12:12:30 +0100
Message-ID: <[e-mail]>
Date: Fri, 08 Aug 2008 12:12:19 +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: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@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:
>  
>
>>--On August 7, 2008 14:56:51 +0200 Simon Josefsson
>><[e-mail]> wrote:
>>    
>>
>>>Chris Newman <[e-mail]> writes:
>>>      
>>>
>>>>While I don't see the utility of making the channel for which EXTERNAL
>>>>applies explicit, I don't object to that either.  However, EXTERNAL
>>>>has been widely used for TLS client certificates.
>>>>        
>>>>
>>>My perception is different: few if any MUAs I've used that supports TLS
>>>client certificates offer the EXTERNAL SASL mechanism for
>>>authentication.  The EXTERNAL specification says that the channel to use
>>>is to be negotiated out-of-band, which makes interoperable use of
>>>EXTERNAL difficult.
>>>
>>>I agree that EXTERNAL sometimes is used for TLS client certificates, but
>>>in my experience that only happens in small environments where the
>>>administrator communicate this knowledge via some special channel.
>>>      
>>>
>>RFC 2595 compliant clients (both POP and IMAP) will use EXTERNAL with
>>STARTTLS and client certificates.  RFC 3501 IMAP clients also have to
>>use EXTERNAL with STARTTLS.  These specifications are not ambiguous on
>>the topic.
>>    
>>
>The EXTERNAL specification is not clear that the TLS channel is the
>intended channel, though, quoting RFC 4422:
>
>   The EXTERNAL mechanism allows a client to request the server to use
>   credentials established by means external to the mechanism to
>   authenticate the client.  The external means may be, for instance, IP
>   Security [RFC4301] or TLS [RFC4346] services.  In absence of some a
>   priori agreement between the client and the server, the client cannot
>   make any assumption as to what external means the server has used to
>   obtain the client's credentials, nor make an assumption as to the
>   form of credentials.  For example, the client cannot assume that the
>   server will use the credentials the client has established via TLS.
>
>RFC 2595 and RFC 3501 says that implementations MAY use EXTERNAL with
>TLS client certificates.  That is correct, but it does not mean that
>EXTERNAL needs to use the TLS channel's credentials.
>
Indeed. The client has no way of knowing for sure if TLS information is 
going to be used by the server end.

>In my perception,
>this ambiguity is the primary reason why EXTERNAL doesn't work well for
>TLS client certificate re-use.
>
>I agree that it would be simpler to revise the EXTERNAL specification to
>say that it is intended to re-use TLS credentials, similar to how we
>have revised GSSAPI to mean Kerberos V5.  I'm not convinced it is
>possible to revise EXTERNAL in this way though, maybe someone is using
>EXTERNAL to refer to an external SSH connection or similar?
>
OpenLDAP uses EXTERNAL when running over a Unix domain socket with no 
TLS. It will use identity from the OS in such cases.

>I would prefer to revise EXTERNAL in this way compared to invent a new mechanism
>though.  Is this a way forward that others find acceptable?
>  
>
IMHO, SASL EXTERNAL as written is underspecified. I would prefer to 
write a separate mechanism which is unambiguous.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m789Miga058369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 02:22:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m789MilI058368; Fri, 8 Aug 2008 02:22: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 m789MfgL058358 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 8 Aug 2008 02:22:43 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KROB8-0001Hq-OE; Fri, 08 Aug 2008 11:22:38 +0200
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> <[e-mail]> <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080808:[e-mail]::HdYF748D0u8+O1td:9zNz
X-Hashcash: 1:22:080808:[e-mail]::4QMqpUfjxrQLZNX/:CYlm
Date: Fri, 08 Aug 2008 11:22:34 +0200
In-Reply-To: <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F> (Chris Newman's message of "Thu, 07 Aug 2008 17:12:41 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> --On August 7, 2008 14:56:51 +0200 Simon Josefsson
> <[e-mail]> wrote:
>> Chris Newman <[e-mail]> writes:
>>
>>> While I don't see the utility of making the channel for which EXTERNAL
>>> applies explicit, I don't object to that either.  However, EXTERNAL
>>> has been widely used for TLS client certificates.
>>
>> My perception is different: few if any MUAs I've used that supports TLS
>> client certificates offer the EXTERNAL SASL mechanism for
>> authentication.  The EXTERNAL specification says that the channel to use
>> is to be negotiated out-of-band, which makes interoperable use of
>> EXTERNAL difficult.
>>
>> I agree that EXTERNAL sometimes is used for TLS client certificates, but
>> in my experience that only happens in small environments where the
>> administrator communicate this knowledge via some special channel.
>
> RFC 2595 compliant clients (both POP and IMAP) will use EXTERNAL with
> STARTTLS and client certificates.  RFC 3501 IMAP clients also have to
> use EXTERNAL with STARTTLS.  These specifications are not ambiguous on
> the topic.

The EXTERNAL specification is not clear that the TLS channel is the
intended channel, though, quoting RFC 4422:

   The EXTERNAL mechanism allows a client to request the server to use
   credentials established by means external to the mechanism to
   authenticate the client.  The external means may be, for instance, IP
   Security [RFC4301] or TLS [RFC4346] services.  In absence of some a
   priori agreement between the client and the server, the client cannot
   make any assumption as to what external means the server has used to
   obtain the client's credentials, nor make an assumption as to the
   form of credentials.  For example, the client cannot assume that the
   server will use the credentials the client has established via TLS.

RFC 2595 and RFC 3501 says that implementations MAY use EXTERNAL with
TLS client certificates.  That is correct, but it does not mean that
EXTERNAL needs to use the TLS channel's credentials.  In my perception,
this ambiguity is the primary reason why EXTERNAL doesn't work well for
TLS client certificate re-use.

I agree that it would be simpler to revise the EXTERNAL specification to
say that it is intended to re-use TLS credentials, similar to how we
have revised GSSAPI to mean Kerberos V5.  I'm not convinced it is
possible to revise EXTERNAL in this way though, maybe someone is using
EXTERNAL to refer to an external SSH connection or similar?  I would
prefer to revise EXTERNAL in this way compared to invent a new mechanism
though.  Is this a way forward that others find acceptable?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7811LW7026291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 18:01:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7811L7i026290; Thu, 7 Aug 2008 18:01:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7811Kd4026283 for <[e-mail]>; Thu, 7 Aug 2008 18:01:20 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7811JSP002565 for <[e-mail]>; Fri, 8 Aug 2008 01:01:20 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 m7811JLG007192 for <[e-mail]>; Thu, 7 Aug 2008 19:01:19 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7811HWa012325; Thu, 7 Aug 2008 20:01:18 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7811ETc012324; Thu, 7 Aug 2008 20:01:14 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 7 Aug 2008 20:01:14 -0500
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Sam Hartman <[e-mail]>, [e-mail], Simon Josefsson <[e-mail]>
Subject: Re: GS2 Encoding: To Escape or Base64
Message-ID: <[e-mail]>
Mail-Followup-To: Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail], Simon Josefsson <[e-mail]>
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]> <CC873BCBA200669DAD719805@446E7922C82D299DB29D899F>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CC873BCBA200669DAD719805@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 Thu, Aug 07, 2008 at 05:03:50PM -0700, Chris Newman wrote:
> --On August 7, 2008 10:54:59 -0400 Sam Hartman <[e-mail]> 
> wrote:
> >There may be a third approach that involves using gss_getmic rather
> >than gss_wrap (thus giving GS2 a bit more control of layout) where the
> >MIC is base64 and the context token if present goes at the end of the
> >message.  That might actually work well for SCRAM, although it's
> >fairly odd to have the context token (which you process first) go at
> >the end of the message.
> 
> That sounds even better, if the GS2 folks are willing.

I don't see how that works.  MIC tokens are typically fixed-sized, but
there's no way to know a priori what that size will be, so we still
have two abritriray-size binary blobs in one message.

> >I think somewhere in here we're going to need a conference call to
> >walk through some options.  However I'd like to have a couple rounds
> >of email to see what some of the constraints are so perhaps we could
> >draw up some specific options to discuss on such a call.
> 
> Now that we're discussing how to simplify rather than whether to simplify, 
> I'm not sure it's controversial enough to require a conference call.

My first choice is escaping.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m780Cjkc023538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 17:12:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m780CjkK023537; Thu, 7 Aug 2008 17:12:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m780CiBi023527 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 7 Aug 2008 17:12:45 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m780CiRi000352 for <[e-mail]>; Thu, 7 Aug 2008 17:12:44 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 07 Aug 2008 17:12:44 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Thu, 07 Aug 2008 17:12:43 -0700 (PDT)
Date: Thu, 07 Aug 2008 17:12:41 -0700
From: Chris Newman <[e-mail]>
Subject: Re: EXTERNAL-CHANNEL
In-reply-to: <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Message-id: <C2E4FD479D227B2E769875FE@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@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 August 7, 2008 14:56:51 +0200 Simon Josefsson <[e-mail]> 
wrote:
> Chris Newman <[e-mail]> writes:
>
>> While I don't see the utility of making the channel for which EXTERNAL
>> applies explicit, I don't object to that either.  However, EXTERNAL
>> has been widely used for TLS client certificates.
>
> My perception is different: few if any MUAs I've used that supports TLS
> client certificates offer the EXTERNAL SASL mechanism for
> authentication.  The EXTERNAL specification says that the channel to use
> is to be negotiated out-of-band, which makes interoperable use of
> EXTERNAL difficult.
>
> I agree that EXTERNAL sometimes is used for TLS client certificates, but
> in my experience that only happens in small environments where the
> administrator communicate this knowledge via some special channel.

RFC 2595 compliant clients (both POP and IMAP) will use EXTERNAL with 
STARTTLS and client certificates.  RFC 3501 IMAP clients also have to use 
EXTERNAL with STARTTLS.  These specifications are not ambiguous on the 
topic.

Both pops and imaps are non-standard but deployed.  All imaps clients 
expect the server to do "* PREAUTH", which is fine (it just means imaps 
doesn't support admin proxy).  The pops implementations can not 
interoperate because that's an under-specified protocol.  It would be good 
if someone fixed the latter.

		- 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 m7804WpH022978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 17:04:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7804WMM022977; Thu, 7 Aug 2008 17:04:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7804S7g022957 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 7 Aug 2008 17:04:29 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7804GTh029754 for <[e-mail]>; Thu, 7 Aug 2008 17:04:28 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 07 Aug 2008 17:04:16 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Thu, 07 Aug 2008 17:03:56 -0700 (PDT)
Date: Thu, 07 Aug 2008 17:03:50 -0700
From: Chris Newman <[e-mail]>
Subject: Re: GS2 Encoding: To Escape or Base64
In-reply-to: <[e-mail]> <[e-mail]>
To: Sam Hartman <[e-mail]>, Nicolas Williams <[e-mail]>
Cc: [e-mail], Simon Josefsson <[e-mail]>
Message-id: <CC873BCBA200669DAD719805@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@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 August 7, 2008 10:54:59 -0400 Sam Hartman <[e-mail]> 
wrote:
> I think there are two basic approaches without lengths.  The first is
> to have two base64 blobs.
> So, ignoring the OID issue, the encoding might be as simple as
> gs2-mesage = base64 SP base64
> (You might want something more complicated as an initial space may be
> undesirable to indicate that a context token is absent)

I'd use something other than a space as the delimiter for the reason you 
mention, but this is an acceptable approach.

> The potential problem with this approach is that it involves a lot of
> layers of base64.  For example in IMAP, a SCRAM message would look
> like a base64 blob containing two base64 blobs.

I don't see this as a problem.  The implementation can likely reuse the 
base64 code and it's not difficult to write an encoder/decoder that 
supports in-place conversion (I'd be glad to share my code if that's 
helpful).  That leaves two places the implementer can screw up security 
(b64 encoder and b64 decoder) and they're both already necessary for most 
SASL profiles.

> Another approach is to use some delimiter.  However the context token
> can contain arbitrary binary data.  At least one part of the integrity
> protected data can include arbitrary binary data.  In the specific
> instance of SCRAM, we can make everything textual or base64.  However
> at a general level we'd need to have some escaping mechanism in case
> the delimiter appeared in the data.  I'd be a bit concerned though if
> SCRAM tended not to use that escaping mechanism that people would get
> it wrong.

While I understand the concern, I suspect we only have to worry about two 
classes of implementers: those who want both SCRAM & Kerberos and use a 
GSSAPI framework and those who only want SCRAM.  If we can design this so 
the latter can use delimiters without escaping and the GS2 spec includes 
Kerberos test vectors showing use of escaping, then I think we're fine. 
That may be better than the extra-base64 option.

> There may be a third approach that involves using gss_getmic rather
> than gss_wrap (thus giving GS2 a bit more control of layout) where the
> MIC is base64 and the context token if present goes at the end of the
> message.  That might actually work well for SCRAM, although it's
> fairly odd to have the context token (which you process first) go at
> the end of the message.

That sounds even better, if the GS2 folks are willing.

> I think somewhere in here we're going to need a conference call to
> walk through some options.  However I'd like to have a couple rounds
> of email to see what some of the constraints are so perhaps we could
> draw up some specific options to discuss on such a call.

Now that we're discussing how to simplify rather than whether to simplify, 
I'm not sure it's controversial enough to require a conference call.

		- 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 m77GJDni091533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 09:19:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77GJDhb091532; Thu, 7 Aug 2008 09:19:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 m77GJC8Q091524 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 7 Aug 2008 09:19:13 -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 m77GJBGL010799 for <[e-mail]>; Thu, 7 Aug 2008 16:19:12 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m77GJ97J038382 for <[e-mail]>; Thu, 7 Aug 2008 10:19:11 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m77GHwbW011751; Thu, 7 Aug 2008 11:18:28 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m77GHqmN011750; Thu, 7 Aug 2008 11:17:52 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 7 Aug 2008 11:17:52 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: GS2 Encoding: To Escape or Base64
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Simon Josefsson <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Aug 07, 2008 at 11:45:31AM -0400, Sam Hartman wrote:
>     Simon> Use 0x00 0xFF to denote end of the data.
> This is a fine approach if we believe escaped delimiter is the way to
> go.

Escaping means that a non-GSS-based SCRAM implementor wouldn't need to
do any escaping if SCRAM is all-ASCII or all-UTF-8.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77Fjdpu089075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 08:45:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77FjdPL089074; Thu, 7 Aug 2008 08:45:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77FjbTA089067 for <[e-mail]>; Thu, 7 Aug 2008 08:45:38 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 99A5F4202; Thu,  7 Aug 2008 11:45:31 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: GS2 Encoding: To Escape or Base64
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Date: Thu, 07 Aug 2008 11:45:31 -0400
In-Reply-To: <[e-mail]> (Simon Josefsson's message of "Thu, 07 Aug 2008 17:20:12 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Simon> Sam Hartman <[e-mail]> writes:
    >> Another approach is to use some delimiter.  However the context
    >> token can contain arbitrary binary data.  At least one part of
    >> the integrity protected data can include arbitrary binary data.
    >> In the specific instance of SCRAM, we can make everything
    >> textual or base64.  However at a general level we'd need to
    >> have some escaping mechanism in case the delimiter appeared in
    >> the data.  I'd be a bit concerned though if SCRAM tended not to
    >> use that escaping mechanism that people would get it wrong.

    Simon> How about using 0x00 as a delimiter?

    Simon> If 0x00 occurs in the data to encode, encode that as 0x00
    Simon> 0x00.

    Simon> Use 0x00 0xFF to denote end of the data.
This is a fine approach if we believe escaped delimiter is the way to
go.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77FKPip087233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 08:20:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77FKPUg087232; Thu, 7 Aug 2008 08:20:25 -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 m77FKMeJ087222 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 7 Aug 2008 08:20:24 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KR7Hj-00019P-5j; Thu, 07 Aug 2008 17:20:19 +0200
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: GS2 Encoding: To Escape or Base64
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080807:[e-mail]::XuYH/BY2XwemZBZx:6efh
X-Hashcash: 1:22:080807:[e-mail]::/WhA5bbZKgEDT+HT:rOjE
X-Hashcash: 1:22:080807:[e-mail]::Zjc12AeOD0dlJvDT:y60V
X-Hashcash: 1:22:080807:[e-mail]::MnQbHyZk+c0p1hL2:Wx3e
Date: Thu, 07 Aug 2008 17:20:12 +0200
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Thu, 07 Aug 2008 10:54:59 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman <[e-mail]> writes:

> Another approach is to use some delimiter.  However the context token
> can contain arbitrary binary data.  At least one part of the integrity
> protected data can include arbitrary binary data.  In the specific
> instance of SCRAM, we can make everything textual or base64.  However
> at a general level we'd need to have some escaping mechanism in case
> the delimiter appeared in the data.  I'd be a bit concerned though if
> SCRAM tended not to use that escaping mechanism that people would get
> it wrong.

How about using 0x00 as a delimiter?

If 0x00 occurs in the data to encode, encode that as 0x00 0x00.

Use 0x00 0xFF to denote end of the data.

Using 0x00 rather than other values has the advantage that normal
zero-termination string function would work if the mechanism tokens are
all-ASCII (modulo the initial OID).  A disadvantage would be that binary
protocols tend to contain a lot of 0x00's.

Personally, my preference is to use base64 though, even if it leads to
double or even triple encoding.  It is easier to get right in
implementations, and easier to debug since it is all ASCII.

/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 m77Et7YB085207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 07:55:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77Et7SB085206; Thu, 7 Aug 2008 07:55:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77Et5Pp085197 for <[e-mail]>; Thu, 7 Aug 2008 07:55:06 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2B779CC9B7; Thu,  7 Aug 2008 10:54:59 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: GS2 Encoding: To Escape or Base64
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F>
Date: Thu, 07 Aug 2008 10:54:59 -0400
In-Reply-To: <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F> (Chris Newman's message of "Wed, 06 Aug 2008 20:22:11 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris, I'd like to start discussing a GS2 encoding.

At a conceptual level, the GS2 layer needs to include two objects in
its challenges and responses.  First, it needs to include a context
token.  Secondly, it needs to include some integrity-protected stuff.
Depending on the state of the exchange, one of these objects may be
absent.

I think there are two basic approaches without lengths.  The first is
to have two base64 blobs.
So, ignoring the OID issue, the encoding might be as simple as 
gs2-mesage = base64 SP base64 
(You might want something more complicated as an initial space may be undesirable to indicate that a context token is absent)

The potential problem with this approach is that it involves a lot of
layers of base64.  For example in IMAP, a SCRAM message would look
like a base64 blob containing two base64 blobs.

Another approach is to use some delimiter.  However the context token
can contain arbitrary binary data.  At least one part of the integrity
protected data can include arbitrary binary data.  In the specific
instance of SCRAM, we can make everything textual or base64.  However
at a general level we'd need to have some escaping mechanism in case
the delimiter appeared in the data.  I'd be a bit concerned though if
SCRAM tended not to use that escaping mechanism that people would get
it wrong.

There may be a third approach that involves using gss_getmic rather
than gss_wrap (thus giving GS2 a bit more control of layout) where the
MIC is base64 and the context token if present goes at the end of the
message.  That might actually work well for SCRAM, although it's
fairly odd to have the context token (which you process first) go at
the end of the message.

I think somewhere in here we're going to need a conference call to
walk through some options.  However I'd like to have a couple rounds
of email to see what some of the constraints are so perhaps we could
draw up some specific options to discuss on such a call.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77Cv5ai076235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 05:57:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77Cv5s0076234; Thu, 7 Aug 2008 05:57:05 -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 m77Cv27O076222 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 7 Aug 2008 05:57:04 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KR531-00018H-GY; Thu, 07 Aug 2008 14:56:57 +0200
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Philip Guenther <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080807:[e-mail]::bjC06Y16Q6dfcZlF:3JGZ
X-Hashcash: 1:22:080807:[e-mail]::RJAkbkyITdX7wFBd:XyJ8
X-Hashcash: 1:22:080807:[e-mail]::lmoo4V9tcpgyQYlq:IK6e
Date: Thu, 07 Aug 2008 14:56:51 +0200
In-Reply-To: <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F> (Chris Newman's message of "Wed, 06 Aug 2008 20:36:48 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> While I don't see the utility of making the channel for which EXTERNAL
> applies explicit, I don't object to that either.  However, EXTERNAL
> has been widely used for TLS client certificates.

My perception is different: few if any MUAs I've used that supports TLS
client certificates offer the EXTERNAL SASL mechanism for
authentication.  The EXTERNAL specification says that the channel to use
is to be negotiated out-of-band, which makes interoperable use of
EXTERNAL difficult.

I agree that EXTERNAL sometimes is used for TLS client certificates, but
in my experience that only happens in small environments where the
administrator communicate this knowledge via some special channel.

> So if we want to change the way EXTERNAL is used I'd prefer to treat
> EXTERNAL as EXTERNAL+TLS-CLIENT-CERT (just like SASL "GSSAPI" is
> Kerberos 5) and create new variants of EXTERNAL for other layers when
> such layers become deployable.  I could see EXTERNAL-PPP being
> possibly viable, for example.

This would mean revising the EXTERNAL specification to say that it means
TLS client-side authentication.  (Note, TLS can use non-certificate
mechanisms such as OpenPGP and SRP too, so restricting it to X.509 would
be sub-optimal.)  That would work for me.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m774KFeP036418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 21:20:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m774KFVM036417; Wed, 6 Aug 2008 21:20:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m774KDFL036408 for <[e-mail]>; Wed, 6 Aug 2008 21:20:13 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m774KDDY022333 for <[e-mail]>; Thu, 7 Aug 2008 04:20:13 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m774KC5c039444 for <[e-mail]>; Wed, 6 Aug 2008 22:20:12 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m774KCLv011479; Wed, 6 Aug 2008 23:20:12 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m774KBtF011478; Wed, 6 Aug 2008 23:20:11 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 6 Aug 2008 23:20:11 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Aug 06, 2008 at 04:36:46PM -0500, Nicolas Williams wrote:
> There is a contradiction here.

Perhaps I misunderstood.  EXTERNAL-CHANNEL seems to be about telling the
server which channel the server should extract user identification
material from for the server's authorization tasks.

Of course, that presumes there can be more than one secure channel in
the stack between the client and the server.  And eventually that will
be possible: an IPsec channel and a TLS channel.  Someday hopefully even
likely.

Therefore EXTERNAL-CHANNEL could indeed be useful.

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 m7747VYX035456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 21:07:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7747V4f035455; Wed, 6 Aug 2008 21: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 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 m7747Ugf035449 for <[e-mail]>; Wed, 6 Aug 2008 21:07:31 -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 m7747Uft010822 for <[e-mail]>; Thu, 7 Aug 2008 04:07:30 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 m7747TxD034502 for <[e-mail]>; Wed, 6 Aug 2008 22:07:29 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7747O1U011451; Wed, 6 Aug 2008 23:07:29 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7747Npk011450; Wed, 6 Aug 2008 23:07:23 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 6 Aug 2008 23:07:23 -0500
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
Message-ID: <[e-mail]>
Mail-Followup-To: Chris Newman <[e-mail]>, Sam Hartman <[e-mail]>, [e-mail]
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <70E4F292E883626158EE81D9@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 Wed, Aug 06, 2008 at 08:22:11PM -0700, Chris Newman wrote:
> For protocol design of small fields like this, I prefer (in order of 
> preference):
> * fixed size fields

In GS2 the context and per-msg tokens cannot be fixed size fields.

> * SASL exchanges are self-delimiting (the SASL profile delimits the
>   SASL message), so if there's only one variable length or binary
>   field at the end of the of each exchange, that's better.

In GS2 we have a round-trip optimization that sometimes requires having
two variable-length opaque tokens in one message, so putting one last
doesn't help.

> * delimited fields where the delimiter can not appear in the field

GSS context and per-message tokens are opaque octet strings, therefore
any octet value can appear, therefore there is no suitable delimiter.

> * delimited fields where the fields have a regular encoding (base64,
>   ascii-hex, etc).

GS2 could base64-encode GSS tokens.

> * delimited fields with escapes (rarely used escapes are more likely
>   to create interop bugs due to implementation flaws than a regular
>   encoding)

GS2 could escape some octet value (and the escape itself).

Given that SCRAM itself could be all-ASCII (or all-UTF-8) we could make
it so SCRAM implementations not done via GS2 need never do any escaping.

I think that makes escaping the winner :)

And we can always compress the standard initial GSS context token header
as a bonus.  That way a non-GSS SCRAM implementation can also avoid that
binary goo and be truly all-text.

> While I can't speak for my co-author, I am almost certain to support making 
> SCRAM a GS2 mechanism is the proposed simplifications to GS2 are made.

I support such simplifications.

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 m773axU3033819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 20:36:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m773axso033818; Wed, 6 Aug 2008 20:36:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-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 m773apJK033805 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 6 Aug 2008 20:36:56 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m773aof2012670 for <[e-mail]>; Wed, 6 Aug 2008 20:36:50 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 06 Aug 2008 20:36:50 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Wed, 06 Aug 2008 20:36:50 -0700 (PDT)
Date: Wed, 06 Aug 2008 20:36:48 -0700
From: Chris Newman <[e-mail]>
Subject: Re: EXTERNAL-CHANNEL
In-reply-to: <[e-mail]>
To: Simon Josefsson <[e-mail]>, Philip Guenther <[e-mail]>
Cc: [e-mail]
Message-id: <EC4AE3FFFBFCBA0DF8843373@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

IPsec is presently useless to applications.  I don't see the authentication 
it provides ever being useful to applications.  However, the security layer 
it provides could be useful if there was a standardized API for an 
application to get an IPsec channel binding and a cipher suite identifier 
(or equivalent).

While I don't see the utility of making the channel for which EXTERNAL 
applies explicit, I don't object to that either.  However, EXTERNAL has 
been widely used for TLS client certificates.  So if we want to change the 
way EXTERNAL is used I'd prefer to treat EXTERNAL as 
EXTERNAL+TLS-CLIENT-CERT (just like SASL "GSSAPI" is Kerberos 5) and create 
new variants of EXTERNAL for other layers when such layers become 
deployable.  I could see EXTERNAL-PPP being possibly viable, for example.

		- Chris

--On August 6, 2008 21:42:47 +0200 Simon Josefsson <[e-mail]> 
wrote:

> Thanks for quick feedback.
>
> Philip Guenther <[e-mail]> writes:
>
>> On Tue, 5 Aug 2008, Chris Newman wrote:
>>> My understanding of channel bindings is they are used to tie the
>>> authentication to the security layer to detect man-in-the-middle attacks
>>> (where the MITM decrypts & re-encrypts all traffic between client &
>>> server). Passing a channel binding in the clear without an
>>> authentication-related hash covering it doesn't do anything as a MITM
>>> can simply modify the channel binding.
>>
>> I agree: the channel binding data must be integrity protected by the
>> layer  passing it for there to be an actual binding to the lower layer
>> that's  immune to MitM attack.
>
> Mea culpa.  However, the MITM problem wasn't my focus.  My use case was
> to make EXTERNAL more usable for re-using TLS client credentials inside
> SASL; right now EXTERNAL assumes out-of-band negotiation between
> administrator and user.  If EXTERNAL would pass the name of the external
> channel that problem with EXTERNAL goes away, and I believe it would be
> sufficient to get TLS-client-auth-propagated-to-SASL more interoperable.
> I'll try to make the use-case more clear in future versions of the
> document.
>
> Perhaps channel bindings is the wrong way to achieve what I want?
> Instead there could be a EXTERNAL-TLS mechanism that explicitly
> reference the outer TLS channel, and protocol-wise is identical to
> EXTERNAL.
>
> The channel bindings mechanism seemed to me like a nice way to abstract
> out which external security channel is intended, which would allow the
> EXTERNAL-CHANNEL to be applicable to IPSec as well.  My use case would
> be solved by a EXTERNAL-TLS though, and I'm not sure that many users are
> interested in re-using IPSec credentials in SASL?
>
>> To acheive the stated goal of indicating which previous-negotiated-at-a-
>> lower-layer client credentials should be used for the SASL
>> authentication  credentials, it appears to me that EXTERNAL-CHANNEL
>> would only need to  pass the channel binding unique prefix.
>
> Yes, I think so.  However, maybe there is some advantage in sending the
> channel bindings as well?  I'm not sure, and would appreciate more
> thinking on this.
>
>> Or is it possible for there to be multiple applicable bindings with the
>> same prefix?  IPsec in IPsec?  Is the unique prefix not actually sure to
>> be unique for a full channel?
>
> I can't think of a situation like that right now, but maybe they exist.
>
> However, what if EXTERNAL-CHANNEL doesn't send the channel bindings in
> clear, but uses it as a HMAC key on the authorization identity?
> Assuming channel bindings aren't predictable and doesn't repeat, that
> would provide some additional assurance, wouldn't it?  In other words,
> the EXTERNAL-CHANNEL token would be:
>
> "tls-unique " HMAC-SHA1(channel-bindings, authz-id) " " authz-id
>
> I'm not convinced this brings significant benefits over a EXTERNAL-TLS
> mechanism though, but I'd be interested to discuss the idea.
>
> /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 m773MJwY032962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 20:22:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m773MJZM032961; Wed, 6 Aug 2008 20:22:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-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 m773MHI3032955 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 6 Aug 2008 20:22:18 -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 m773MFdZ012195 for <[e-mail]>; Wed, 6 Aug 2008 20:22:17 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 06 Aug 2008 20:22:15 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Wed, 06 Aug 2008 20:22:13 -0700 (PDT)
Date: Wed, 06 Aug 2008 20:22:11 -0700
From: Chris Newman <[e-mail]>
Subject: Re: Scram as a gs2 mechanism ABNF
In-reply-to: <[e-mail]>
To: Nicolas Williams <[e-mail]>, Sam Hartman <[e-mail]>
Cc: [e-mail]
Message-id: <70E4F292E883626158EE81D9@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On August 6, 2008 14:48:53 -0500 Nicolas Williams 
<[e-mail]> wrote:

> On Wed, Aug 06, 2008 at 02:45:44PM -0400, Sam Hartman wrote:
>>     Chris> [...]
>>
>> I think that this argument applies equally well to GS2 as it does to
>> scram.  We should not have standards for what is good protocol design
>> that differ between two protocols in the same working group.  So, if
>> lengths are bad, let's remove them from GS2.  If lengths are OK, then
>> they should be OK for scram.  I don't care very much whether we decide
>> lengths are fine or problematic.
>
> Assuming Crhis' main objection is to the binary/non-textual bits on the
> wire, then we could:
>
>  - base64-encode GSS tokens in GS2 and remove the length fields in GS2
>
>  and
>
>  - "compress" the standard initial token mechanism OID header, as
>    discussed before
>
> Then an all-ASCII ABNF for GS2/SCRAM will be possible.
>
> Chris, Simon, please comment.

It's my opinion the amount of data in this context never requires a length 
field and such fields are complex and error prone at this layer (length 
fields are useful for large objects and chunking of large objects).  I 
point to the numerous security bugs in ASN.1, PKIX, and Kerberos libraries 
as evidence that lengths (especially nested lengths) are a security problem 
for design.  While textual protocols that use delimiters have security bugs 
too, they are significantly less frequent in practice in my experience.

For protocol design of small fields like this, I prefer (in order of 
preference):
 * fixed size fields
 * SASL exchanges are self-delimiting (the SASL profile delimits the SASL 
message), so if
   there's only one variable length or binary field at the end of the of 
each exchange,
   that's better.
 * delimited fields where the delimiter can not appear in the field
 * delimited fields where the fields have a regular encoding (base64, 
ascii-hex, etc).
 * delimited fields with escapes (rarely used escapes are more likely to 
create interop
   bugs due to implementation flaws than a regular encoding)

I also prefer textual over binary as it simplifies examples and test 
vectors, but that's secondary to the above priority list.

While I can't speak for my co-author, I am almost certain to support making 
SCRAM a GS2 mechanism is the proposed simplifications to GS2 are made.

		- 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 m76LamTl012600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 14:36:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76LamAI012599; Wed, 6 Aug 2008 14:36: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-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76Lamc2012591 for <[e-mail]>; Wed, 6 Aug 2008 14:36:48 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m76Lam3a004878 for <[e-mail]>; Wed, 6 Aug 2008 21:36:48 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 m76LalJ9060313 for <[e-mail]>; Wed, 6 Aug 2008 15:36:48 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m76LaluG011234; Wed, 6 Aug 2008 16:36:47 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m76Lak8R011233; Wed, 6 Aug 2008 16:36:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 6 Aug 2008 16:36:46 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: EXTERNAL-CHANNEL
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Aug 05, 2008 at 08:43:50PM +0200, Simon Josefsson wrote:
> > This document describes a way to perform end-user authentication in
> > the Simple Authentication and Security Layer (SASL) framework which
> > re-use an external security layer (such as the Transport Layer
> > Security (TLS) protocol) that may have already completed end-user
> > authentication.  In comparison with the existing EXTERNAL mechanism,
> > this mechanism offers a way to cryptographically bind the
> > authentication to the security layer via a channel binding.  The
> > EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made
> > by the design of the EXTERNAL mechanism.

There is a contradiction here.

We have a lower-layer channel providing both, authentication and
transport protection.  Any binding between the two had better be done at
that layer, and it had better be done!

No mechanism like EXTERNAL can do any sort of cryptographic binding of
authentication and secure channel because EXTERNAL-like mechanisms have
no cryptographic key material available that is suitable for that task
(considering too that any such binding has to be difficult for MITMs to
defeat).

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 m76L8QQ5010436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 14:08:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76L8QqP010435; Wed, 6 Aug 2008 14:08:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76L8PZX010426 for <[e-mail]>; Wed, 6 Aug 2008 14:08:26 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m76L8PmA013142 for <[e-mail]>; Wed, 6 Aug 2008 21:08:25 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m76L8PIO044559 for <[e-mail]>; Wed, 6 Aug 2008 15:08:25 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m76L8OGC011210; Wed, 6 Aug 2008 16:08:24 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m76L8FFj011209; Wed, 6 Aug 2008 16:08:15 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 6 Aug 2008 16:08:15 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
Message-ID: <[e-mail]>
Mail-Followup-To: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <3004E59C41417C7EEF78588C@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 Wed, Aug 06, 2008 at 10:15:24PM +0200, Simon Josefsson wrote:
> Textual protocols are easier to debug and can be easier to implement in
> some languages.  One problem is if textual protocol permits complex
> rules like DIGEST-MD5.  It will require some work to rewrite GS2 though.
> 
> If rewriting GS2 will make SCRAM become a GSS-API mechanism (and used in
> SASL under GS2), I'll happily do the GS2 work involved.  But if SCRAM
> remains as a SASL mechanism, I don't see the advantage in changing GS2
> for this.

Yes, the point is to end up with SCRAM as a GSS-API mechanism only, but
such that SASL implementors can implement SCRAM without having to
implement GS2 and GSS frameworks.

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 m76L6vf7010342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 14:06:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76L6vjS010341; Wed, 6 Aug 2008 14:06:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76L6uXq010334 for <[e-mail]>; Wed, 6 Aug 2008 14:06:57 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m76L6tvs020215 for <[e-mail]>; Wed, 6 Aug 2008 21:06:55 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m76L6twF043784 for <[e-mail]>; Wed, 6 Aug 2008 15:06:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m76L6sdg011203; Wed, 6 Aug 2008 16:06:55 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m76L6sP6011202; Wed, 6 Aug 2008 16:06:54 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 6 Aug 2008 16:06:54 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <3004E59C41417C7EEF78588C@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 Wed, Aug 06, 2008 at 04:01:15PM -0400, Sam Hartman wrote:
>     Nicolas>  - base64-encode GSS tokens in GS2 and remove the length
>     Nicolas> fields in GS2
> 
> You probably do not want to base64 encode the GSS-data.  That will get
> you ascii, but with multiple layers of base64, which may be as bad as
> lengths.  I think you want to have an escaped terminator and avoid as
> much encoding as possible.

Multiple layers of base64 encoding don't hurt, though we could certainly
make GS2 avoid it.  Escaping would work.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76KG6B9006528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 13:16:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76KG6J7006527; Wed, 6 Aug 2008 13:16:06 -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 m76KG3ZD006517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 6 Aug 2008 13:16:06 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KQpQI-00010F-FE; Wed, 06 Aug 2008 22:16:00 +0200
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080806:[e-mail]::T46xWVs3MZmhwSZs:G8Zy
X-Hashcash: 1:22:080806:[e-mail]::r4QibAaL5uT6t03W:IUbE
X-Hashcash: 1:22:080806:[e-mail]::bfFuMwkixkPNEBeL:BJgU
Date: Wed, 06 Aug 2008 22:15:24 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 6 Aug 2008 14:48:53 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Wed, Aug 06, 2008 at 02:45:44PM -0400, Sam Hartman wrote:
>>     Chris> [...]
>> 
>> I think that this argument applies equally well to GS2 as it does to
>> scram.  We should not have standards for what is good protocol design
>> that differ between two protocols in the same working group.  So, if
>> lengths are bad, let's remove them from GS2.  If lengths are OK, then
>> they should be OK for scram.  I don't care very much whether we decide
>> lengths are fine or problematic.
>
> Assuming Crhis' main objection is to the binary/non-textual bits on the
> wire, then we could:
>
>  - base64-encode GSS tokens in GS2 and remove the length fields in GS2
>  
>  and
>
>  - "compress" the standard initial token mechanism OID header, as
>    discussed before
>
> Then an all-ASCII ABNF for GS2/SCRAM will be possible.
>
> Chris, Simon, please comment.

Textual protocols are easier to debug and can be easier to implement in
some languages.  One problem is if textual protocol permits complex
rules like DIGEST-MD5.  It will require some work to rewrite GS2 though.

If rewriting GS2 will make SCRAM become a GSS-API mechanism (and used in
SASL under GS2), I'll happily do the GS2 work involved.  But if SCRAM
remains as a SASL mechanism, I don't see the advantage in changing GS2
for this.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76K37sn004715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 13:03:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76K37eO004714; Wed, 6 Aug 2008 13:03:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 m76K30BN004701 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 6 Aug 2008 13:03:07 -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 m76K30In019768 for <[e-mail]>; Wed, 6 Aug 2008 20:03:00 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m76K2xSj062118 for <[e-mail]>; Wed, 6 Aug 2008 14:02:59 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m76K2xPL011113; Wed, 6 Aug 2008 15:02:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m76K2u0X011112; Wed, 6 Aug 2008 15:02:56 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 6 Aug 2008 15:02:56 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <3004E59C41417C7EEF78588C@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 Wed, Aug 06, 2008 at 02:45:44PM -0400, Sam Hartman wrote:
>     Chris> I am confused about why the channel-binding may appear
>     Chris> twice.  Can you explain?
> 
> I am too.
> I gave you an explanation for this in person which seems wrong looking at the ABNF.
> Channel binding should appear once in the wrap part of the message.
> 
> Nico, is this just an error?

The first appearance of it in scram-c2-wrap was meant to be
channel-binding-length.  So yes, it's a typo.

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 m76K1L9c004631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 13:01:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76K1LXo004630; Wed, 6 Aug 2008 13:01:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76K1Jd0004623 for <[e-mail]>; Wed, 6 Aug 2008 13:01:20 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BAC7447CC; Wed,  6 Aug 2008 16:01:15 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Date: Wed, 06 Aug 2008 16:01:15 -0400
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 6 Aug 2008 14:48:53 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Nicolas> On Wed, Aug 06, 2008 at 02:45:44PM -0400, Sam Hartman
    Nicolas> wrote:
    Chris> [...]
    >>  I think that this argument applies equally well to GS2 as it
    >> does to scram.  We should not have standards for what is good
    >> protocol design that differ between two protocols in the same
    >> working group.  So, if lengths are bad, let's remove them from
    >> GS2.  If lengths are OK, then they should be OK for scram.  I
    >> don't care very much whether we decide lengths are fine or
    >> problematic.

    Nicolas> Assuming Crhis' main objection is to the
    Nicolas> binary/non-textual bits on the wire, then we could:

    Nicolas>  - base64-encode GSS tokens in GS2 and remove the length
    Nicolas> fields in GS2

You probably do not want to base64 encode the GSS-data.  That will get
you ascii, but with multiple layers of base64, which may be as bad as
lengths.  I think you want to have an escaped terminator and avoid as much encoding as possible.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76Jn5pu003757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 12:49:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76Jn58j003756; Wed, 6 Aug 2008 12:49:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 m76Jn4rP003750 for <[e-mail]>; Wed, 6 Aug 2008 12:49:04 -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 m76Jn3vN012101 for <[e-mail]>; Wed, 6 Aug 2008 19:49:04 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m76Jn3dw053759 for <[e-mail]>; Wed, 6 Aug 2008 13:49:03 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m76Jn21d011100; Wed, 6 Aug 2008 14:49:02 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m76JmsTU011099; Wed, 6 Aug 2008 14:48:54 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 6 Aug 2008 14:48:53 -0500
From: Nicolas Williams <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
Message-ID: <[e-mail]>
Mail-Followup-To: Sam Hartman <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
References: <[e-mail]> <3004E59C41417C7EEF78588C@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 Wed, Aug 06, 2008 at 02:45:44PM -0400, Sam Hartman wrote:
>     Chris> [...]
> 
> I think that this argument applies equally well to GS2 as it does to
> scram.  We should not have standards for what is good protocol design
> that differ between two protocols in the same working group.  So, if
> lengths are bad, let's remove them from GS2.  If lengths are OK, then
> they should be OK for scram.  I don't care very much whether we decide
> lengths are fine or problematic.

Assuming Crhis' main objection is to the binary/non-textual bits on the
wire, then we could:

 - base64-encode GSS tokens in GS2 and remove the length fields in GS2
 
 and

 - "compress" the standard initial token mechanism OID header, as
   discussed before

Then an all-ASCII ABNF for GS2/SCRAM will be possible.

Chris, Simon, please comment.

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 m76Jh6EN003269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 12:43:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76Jh6IJ003268; Wed, 6 Aug 2008 12:43:06 -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 m76Jh3Um003261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 6 Aug 2008 12:43:05 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KQouO-000100-12; Wed, 06 Aug 2008 21:42:59 +0200
From: Simon Josefsson <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080806:[e-mail]::6eRopHxJz1bP5eCj:314o
X-Hashcash: 1:22:080806:[e-mail]::62psPMltzSVRFV2M:Atpj
X-Hashcash: 1:22:080806:[e-mail]::McGub8pLminYyvMO:I/l0
Date: Wed, 06 Aug 2008 21:42:47 +0200
In-Reply-To: <[e-mail]> (Philip Guenther's message of "Wed, 6 Aug 2008 11:58:14 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for quick feedback.

Philip Guenther <[e-mail]> writes:

> On Tue, 5 Aug 2008, Chris Newman wrote:
>> My understanding of channel bindings is they are used to tie the
>> authentication to the security layer to detect man-in-the-middle attacks
>> (where the MITM decrypts & re-encrypts all traffic between client & server).
>> Passing a channel binding in the clear without an authentication-related hash
>> covering it doesn't do anything as a MITM can simply modify the channel
>> binding.
>
> I agree: the channel binding data must be integrity protected by the layer 
> passing it for there to be an actual binding to the lower layer that's 
> immune to MitM attack.

Mea culpa.  However, the MITM problem wasn't my focus.  My use case was
to make EXTERNAL more usable for re-using TLS client credentials inside
SASL; right now EXTERNAL assumes out-of-band negotiation between
administrator and user.  If EXTERNAL would pass the name of the external
channel that problem with EXTERNAL goes away, and I believe it would be
sufficient to get TLS-client-auth-propagated-to-SASL more interoperable.
I'll try to make the use-case more clear in future versions of the
document.

Perhaps channel bindings is the wrong way to achieve what I want?
Instead there could be a EXTERNAL-TLS mechanism that explicitly
reference the outer TLS channel, and protocol-wise is identical to
EXTERNAL.

The channel bindings mechanism seemed to me like a nice way to abstract
out which external security channel is intended, which would allow the
EXTERNAL-CHANNEL to be applicable to IPSec as well.  My use case would
be solved by a EXTERNAL-TLS though, and I'm not sure that many users are
interested in re-using IPSec credentials in SASL?

> To acheive the stated goal of indicating which previous-negotiated-at-a- 
> lower-layer client credentials should be used for the SASL authentication 
> credentials, it appears to me that EXTERNAL-CHANNEL would only need to 
> pass the channel binding unique prefix.

Yes, I think so.  However, maybe there is some advantage in sending the
channel bindings as well?  I'm not sure, and would appreciate more
thinking on this.

> Or is it possible for there to be multiple applicable bindings with the 
> same prefix?  IPsec in IPsec?  Is the unique prefix not actually sure to 
> be unique for a full channel?

I can't think of a situation like that right now, but maybe they exist.

However, what if EXTERNAL-CHANNEL doesn't send the channel bindings in
clear, but uses it as a HMAC key on the authorization identity?
Assuming channel bindings aren't predictable and doesn't repeat, that
would provide some additional assurance, wouldn't it?  In other words,
the EXTERNAL-CHANNEL token would be:

"tls-unique " HMAC-SHA1(channel-bindings, authz-id) " " authz-id

I'm not convinced this brings significant benefits over a EXTERNAL-TLS
mechanism though, but I'd be interested to discuss the idea.

/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 m76IwQp9099741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 11:58:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76IwQP2099740; Wed, 6 Aug 2008 11:58:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76IwKCa099728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 6 Aug 2008 11:58:26 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m76J3cG5004973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Aug 2008 12:03:38 -0700
Received: from [192.168.0.4] (ip70-176-56-239.ph.ph.cox.net [70.176.56.239]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m76IwE1Q011514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 11:58:15 -0700
Date: Wed, 6 Aug 2008 11:58:14 -0700
From: Philip Guenther <[e-mail]>
To: Chris Newman <[e-mail]>
cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: EXTERNAL-CHANNEL
In-Reply-To: <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F>
User-Agent: Alpine 1.10 (BSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MM-Ex-RefId: 149371::080806115816-11FAFB90-77AD6E7A/0-0/0-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 5 Aug 2008, Chris Newman wrote:
> My understanding of channel bindings is they are used to tie the
> authentication to the security layer to detect man-in-the-middle attacks
> (where the MITM decrypts & re-encrypts all traffic between client & server).
> Passing a channel binding in the clear without an authentication-related hash
> covering it doesn't do anything as a MITM can simply modify the channel
> binding.

I agree: the channel binding data must be integrity protected by the layer 
passing it for there to be an actual binding to the lower layer that's 
immune to MitM attack.

To acheive the stated goal of indicating which previous-negotiated-at-a- 
lower-layer client credentials should be used for the SASL authentication 
credentials, it appears to me that EXTERNAL-CHANNEL would only need to 
pass the channel binding unique prefix.

Or is it possible for there to be multiple applicable bindings with the 
same prefix?  IPsec in IPsec?  Is the unique prefix not actually sure to 
be unique for a full channel?


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76IjpQ5098384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 11:45:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76IjpOf098382; Wed, 6 Aug 2008 11:45:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76IjnnE098365 for <[e-mail]>; Wed, 6 Aug 2008 11:45:50 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AF44F47CC; Wed,  6 Aug 2008 14:45:44 -0400 (EDT)
From: Sam Hartman <[e-mail]>
To: Chris Newman <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: Re: Scram as a gs2 mechanism ABNF
References: <[e-mail]> <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F>
Date: Wed, 06 Aug 2008 14:45:44 -0400
In-Reply-To: <3004E59C41417C7EEF78588C@446E7922C82D299DB29D899F> (Chris Newman's message of "Wed, 30 Jul 2008 19:01:42 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

    Chris> --On July 29, 2008 8:12:40 -0400 Sam Hartman
    Chris> <[e-mail]> wrote:
    >> Here are Nico and my notes on scram as a GSS-API mechanism.
    >> 
    >> My hope is that Chris and others will find this acceptable.

    Chris> FYI, I am not likely to find this protocol acceptable, but
    Chris> I want to make sure I understand the protocol before I
    Chris> commit one way or the other.  At this point, I do not
    Chris> understand the "mac" rule and need to confirm my
    Chris> assumptions.

We discussed some of this in person, but I want to follow up for the list.

    Chris> My basis for evaluating this protocol relative to the
    Chris> current SCRAM protocol is as follows:

    Chris> I recognize a modest benefit in code sharing,
    Chris> deployment/implementation/interoperability if a SCRAM-GS2
    Chris> mechanism and a SCRAM-SASL mechanism use the same
    Chris> bits-on-the-wire as both a GSSAPI-guru and a SASL-app-guy
    Chris> can implement in their comfort zone.  I contrast that with
    Chris> separate SCRAM-GS2 used for things like NFS that are GSSAPI
    Chris> only, and SCRAM-SASL used for things that support SASL.  In
    Chris> that case, there's risk of the GSSAPI mechanism leaking
    Chris> through in a SASL-based protocol (even if we say SHOULD
    Chris> NOT) and introducing interop problems -- much the way
    Chris> GSS-SPNEGO leaked into SASL.  

I think that if we design separate gss-scram and scram SASL mechanisms
we should expect that some applications will use GSS-SCRAM as a SASL
mechanism.  I would object to us saying that this SHOULD NOT happen
because there is no reasonable way for a SASL implementation to know whether some GSS-API mechanism corresponds to another SASL mechanism or not.
With SPNEGO, we got lucky because we  needed to revise the GSS-API SASL binding.
The only way I can see limiting this is to assume that by default a GSS-API mechanism should not be used with SASL.
I would object  to that in the strongest possible terms.

So, I think that if we design separate mechanisms we should expect
that platforms that tend to use GSS-API will offer the GSS version in
SASL dialogues.  Whether these same platforms will also offer SASL
versions will depend on a lot of factors.  Of course whether an
application supports one or both will depend on a lot of factors.
Applications that tend to use a full-featured SASL framework will be
more likely to support both versions than applications that hard-code
a set of SASL mechanisms.

    Chris> Regardless, if SCRAM is to
    Chris> succeed it needs to be implemented in multiple frameworks
    Chris> (HTTP-Auth, SASL, GSSAPI, SSH-auth, perhaps EAP).  

Note that HTTP, SSH and SASL all support GSS-API.  I can understand
claiming that the HTTP support for GSS-API is a bit esthetically displeasing.

I agree though that for scram to be successful it needs to be
available in all these situations.  My primary goals are two-fold: to
reduce security analysis and to make sure that choice of application
substrate does not influence choice of security technology.  So, if
SCRAM was not going to have the same over-the-wire bits as GS2, then
I'd be a lot happier if we did more than just a SASL mechanism.
First, that would allow us to do the security analysis for all the
mechanisms at once.  Second, it would give confidence that scram was
at least going to have the standardization energy necessary to
succeed.

    Chris> So the benefit of potentially eliminating one framework is
    Chris> only a modest benefit.

Obviously we disagree on this point.

    Chris> I contrast that with the additional complexity of
    Chris> implementing a pure SASL mechanism.  GSSAPI is not an
    Chris> app-level protocol; it's an OS-level protocol when present.
    Chris> Deploying things in the OS often takes longer than
    Chris> deploying them in the app layer.  So I consider the cost of
    Chris> deploying the SASL mechanism the overriding consideration
    Chris> in terms of actually getting this mechanism deployed.

    Chris> Constant binary strings are ugly, but tolerable especially
    Chris> if they are few and only a prefix or postfix.  A length is
    Chris> much more problematic (regardless of whether or not it is
    Chris> binary).  Each computed length is an opportunity for a
    Chris> buffer overflow implementation bug and thus makes the
    Chris> protocol itself less secure when it enters the real world.
    Chris> A security advisory saying SCRAM is insecure due to a
    Chris> buffer overflow in someone's implementation would do harm
    Chris> to SCRAM deployment.

I think that this argument applies equally well to GS2 as it does to
scram.  We should not have standards for what is good protocol design
that differ between two protocols in the same working group.  So, if
lengths are bad, let's remove them from GS2.  If lengths are OK, then
they should be OK for scram.  I don't care very much whether we decide
lengths are fine or problematic.



    Chris> I am assuming the "4*octet" is a big-endian 32-bit unsigned
    Chris> integer octet count of part of the protocol.  I am assuming
    Chris> ctx-length covers the "context" (for each exchange
    Chris> respectively: scram-c1, scram-s1, scram-c2-ctx,
    Chris> scram-s2-ctx).  I am assuming wrap-length covers the
    Chris> "wrapped" portion of each exchange (respectively: 0, 0,
    Chris> scram-c2-wrap, scram-s2-wrap).
Your assumptions are correct to the best of my understanding.


    >> der-definite-length = %00-%7F / %81 octet / %82 2*octet / %83
    >> 3*octet / %84 4*octet
    >> 
    >> gss-init-ctx-header = %60 der-definite-length "<constant
    >> encoded OID octet string here>"

    Chris> I am assuming that the "der-definite-length" is the length
    Chris> of the encoded OID only.  I presume gss-init-ctx-header
    Chris> will collapse to a constant octet string for each SCRAM
    Chris> mechanism name and no SCRAM implementation will be required
    Chris> to generate a DER ASN.1 length for this purpose.
Unfortunately, no. Section 3.1 of RFC 2743 says that the length needs to cover the entire token.
If the working group agrees that this is too ugly, I think we have two approaches:

* Move the complexity into general purpose GS2 mechanisms.
Require that if the GSS-API token starts with the header defined in RFC 2743  section 3.1, then that header is removed and replaced with a SASL-friendly representation.
The over-the-wire encoding might look something like 
"OID=1.2.3.99212.24 DATA=base64stuffgoeshere"
The receiving side reconstructs the GSS-API glop.
The assumption here is that it's OK if a general purpose GS2 mechanism needs to be more complicated than the wire encoding for SASL.

* Relax RFC 2743 3.1 so that the length covers items 2-5 but MAY or MAY NOT need to cover  the following mechanism-specific data.
I actually suspect that would be a harmless change.
The assumption here is that GSS-API is too complicated for everyone and we should fix it.

    >> 
    >> mac = "m=" base64 ";" ;; This is a GSS wrap with integrity
    >> token for SCRAM; normally ;; this is all it will be, but a true
    >> SCRAM GSS mechanism may ;; have sequence numbers too

    Chris> I do not understand where the content of the base64 comes
    Chris> from.  How is the content computed by a SCRAM
    Chris> implementation with no GSSAPI library present?
This would simply be the hmac-whatever of the data being mac'd.  Nico
wants the ability to have extensions in the MAC string used for
sequencing that would not show up in SASL.  In other words, we'd like
to include non-critical extensions there.
You would use those extensions in  providing sequencing for raw GSS-API applications.

    >> channel-binding = *(octet)
    >> 
    >> scram-c2-ctx = nonce "," proof scram-c2-wrap = mac "," 4*%00
    >> channel-binding 4*octet %00 [channel-binding] [authzid]
    >> scram-c2 = gs2-header scram-c2-ctx scram-c2-wrap

    Chris> I am confused about why the channel-binding may appear
    Chris> twice.  Can you explain?

I am too.
I gave you an explanation for this in person which seems wrong looking at the ABNF.
Channel binding should appear once in the wrap part of the message.

Nico, is this just an error?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76IKW5L096396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 11:20:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76IKWmp096395; Wed, 6 Aug 2008 11:20:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76IKOiA096385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 6 Aug 2008 11:20:30 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m76IKCkm029484 for <[e-mail]>; Wed, 6 Aug 2008 11:20:24 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 06 Aug 2008 11:20:12 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Wed, 06 Aug 2008 11:20:10 -0700 (PDT)
Date: Tue, 05 Aug 2008 18:37:54 -0700
From: Chris Newman <[e-mail]>
Subject: Re: EXTERNAL-CHANNEL
In-reply-to: <[e-mail]>
To: Simon Josefsson <[e-mail]>, [e-mail]
Message-id: <C945D3885205DDE64FE07F9B@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do not understand the value of passing the channel binding within this 
context.  I must be missing something.  Let me explain my thinking so you 
can spot my error.

My understanding of channel bindings is they are used to tie the 
authentication to the security layer to detect man-in-the-middle attacks 
(where the MITM decrypts & re-encrypts all traffic between client & 
server).  Passing a channel binding in the clear without an 
authentication-related hash covering it doesn't do anything as a MITM can 
simply modify the channel binding.

If the authentication and security layer are done at the same level of the 
protocol stack and that level is implemented correctly, then channel 
bindings are implicit at that layer of the stack and provide no value at 
higher levels of the stack.

Now a case where something akin to channel bindings would be useful is if 
the security layer and authentication were at separate layers of the 
protocol stack.  One scenario I can think of for this is if IPsec is used 
for the security layer and TLS_RSA_WITH_NULL_NULL is used for client cert 
authentication at the TLS layer.  Then a SASL mechanism which did an HMAC 
of the client cert authentication session key with the IPsec channel 
bindings would be a value add (pardon me if I didn't use quite the right 
terminology here -- I'm trying to explain intent not details).

		- Chris

--On August 5, 2008 20:43:50 +0200 Simon Josefsson <[e-mail]> 
wrote:
> All,
>
> Below is the announcement of a document that describes a variant of the
> EXTERNAL mechanism that can transfer a channel bindings.  It will
> hopefully make client-side authentication via TLS more easily usable
> from SASL.  Comments and feedback are appreciated.  Before I seek an AD
> to proceed with individual publication, is this something the WG wants
> to adopt?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m75IippM086007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2008 11:44:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m75IipSL086006; Tue, 5 Aug 2008 11:44:51 -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 m75Iinnr085997 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 5 Aug 2008 11:44:50 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KQRWJ-0000ko-Iz for [e-mail]; Tue, 05 Aug 2008 20:44:45 +0200
X-Hashcash: 1:22:080805:[e-mail]::X1VwDL69R5ogX0l/:PMy0
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: EXTERNAL-CHANNEL
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080805:[e-mail]::SWfosWcVhXfa/cOi:E37Z
X-Hashcash: 1:22:080805:[e-mail]::aWzxSHugg09AIXtF:Pm7x
Date: Tue, 05 Aug 2008 20:43:50 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Tue, 5 Aug 2008 11:15:01 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Below is the announcement of a document that describes a variant of the
EXTERNAL mechanism that can transfer a channel bindings.  It will
hopefully make client-side authentication via TLS more easily usable
from SASL.  Comments and feedback are appreciated.  Before I seek an AD
to proceed with individual publication, is this something the WG wants
to adopt?

/Simon

[e-mail] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism for External Authentication using Channel Bindings: EXTERNAL-CHANNEL
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-00.txt
> 	Pages           : 10
> 	Date            : 2008-08-05
>
> This document describes a way to perform end-user authentication in
> the Simple Authentication and Security Layer (SASL) framework which
> re-use an external security layer (such as the Transport Layer
> Security (TLS) protocol) that may have already completed end-user
> authentication.  In comparison with the existing EXTERNAL mechanism,
> this mechanism offers a way to cryptographically bind the
> authentication to the security layer via a channel binding.  The
> EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made
> by the design of the EXTERNAL mechanism.
>
> See <http://josefsson.org/external-channel/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m75I6e1P083179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Aug 2008 11:06:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m75I6eGQ083178; Tue, 5 Aug 2008 11:06:40 -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 m75I6cwA083171 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 5 Aug 2008 11:06:39 -0700 (MST) (envelope-from [e-mail])
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m75I6Qk0014557 for <[e-mail]>; Tue, 5 Aug 2008 11:06:38 -0700 (PDT)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 05 Aug 2008 11:06:26 -0700 (PDT)
Received: from [10.1.110.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Tue, 05 Aug 2008 11:05:58 -0700 (PDT)
Date: Tue, 05 Aug 2008 11:05:56 -0700
From: Chris Newman <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
In-reply-to: <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Lyndon Nerenberg <[e-mail]>
Cc: [e-mail]
Message-id: <FC81591FE11E549E41AF63E8@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On August 1, 2008 10:55:06 +0100 Kurt Zeilenga <[e-mail]> 
wrote:
> 2) seek a waiver from the IESG of certain requirements placed upon SASL
> mechanism specifications (such as RFC 4422
> requirement that mechanism specifications detail how character data
> inputs to cryptographic functions be precisely specified to ensure
> interoperability), or

The right way to do this is to put text in the document mentioning the rule 
and explaining why it's not being followed in this case.  Then the IETF 
last call and IESG just evaluate the document like any other and are 
approving that text along with the rest of it.

		- Chris



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m752FdlM011254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 19:15:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m752Fd8V011253; Mon, 4 Aug 2008 19:15:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m752FUam011244 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 4 Aug 2008 19:15:37 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KQC58-0001gT-H6 for [e-mail]; Tue, 05 Aug 2008 02:15:26 +0000
Received: from 212.82.251.12 ([212.82.251.12]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Aug 2008 02:15:26 +0000
Received: from nobody by 212.82.251.12 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Tue, 05 Aug 2008 02:15:26 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date:  Tue, 5 Aug 2008 04:16:21 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 90
Message-ID: <g78d3k$cu$[e-mail]>
References:  <[e-mail]> <834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]> <[e-mail]> <[e-mail]> <g6vnus$mt5$[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.12
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> I believe there is a consensus in this WG that CRAM-MD5
> in its current form is not a meechanism we want people
> to continue to adopt and deploy

Then the WG is in conflict with its Charter.  It had no
such difficulties with PLAIN.  A promotion on standards
track requires two interoperable implementations, there's
no lack of interoperable CRAM-MD5 implementations. =20

The SASL implementation reports posted here so far all
offered CRAM-MD5 among others, and nobody mentioned any
interoperability issues.  Promotion on standards track
is no popularity contest.  Within the limits of what
HMAC is supposed and able to do CRAM-MD5 does this.

> You can of course argue within the WG that this is not
> the best course of action

I'm not more arguing "within" the WG, it's quite clear
that this WG doesn't intend to follow IETF rules as I
understand them.  The WG intends to kick CRAM-MD5 from
the standards track for reasons not stated in RFC 2026,
blocking an in theory simple CRAM-MD5 update for years.

> You can also participate in the ongoing discussion as
> to what the next charter should look like.

I'm mostly interested in the current Charter.  Unless
folks change their mind about deprecating DIGEST-MD5=20
I've mentioned one missing point in the current draft.

Wrt SASLprep I've asked if RFC 5198 might be a better
approach.  For SCRAM nobody was interested to look at
RMX as HMAC-alternative, and for HMAC-MD5 folks here
apparently intend to ignore what others said about it.

Apart from that I've nothing to contribute to the next
WG Charter, promoting RFC 4422 is fine.

> I do not expect that the IESG will allow you to=20
> ignore that consensus and bypass the working group
> by directly submitting individual work that overlaps
> the area of responsibility of an active working group.

They could decide to follow RFC 2026 and the WG Charter.
There was no much WG activity in the last months.  The
last time something interesting happened (from my POV)
was when HEXA, SCRAM, and YAP were posted (2007-02),
and when DIGEST-MD5 was apparently deprecated (2007-03).

Which was rather harsh after the efforts that went into
2831bis-12, but arguably it was a stop-loss decision.

> "erroneous or intentional lie" is inflammatory

Yes, that's what it is.  And it reflects what I think
about what's going on here wrt CRAM-MD5, an attempt to
block or kill anything that's unrelated to GS2.  It is
fine if folks work on what they are really interested
in, maybe they should get it in the WG Charter at some
point in time.  But what is the purpose of blocking or
killing CRAM-MD5 ?  Were the technical reasons against
DIGEST-MD5 the _real_ reasons to kill 2831bis ?=20

> The usage column in the registry describes the=20
> _intended use_ of the mechanism, not how widely
> deployed it is.  See section 7 of RFC4422.

Mandatory in several standards, the only incarnation
of a SASL mechanism for ESMTPA in real deployment, and
honourably mentioned in BCP 46.  That *is* as COMMON
as it can get.  More than some other COMMON mechanisms,
notably DIGEST-MD5 if the decision here to deprecate
it holds.  CRAM-MD5 could be an example of a "wildly
successful protocol" in the IAB RFC discussing such
examples.  A bit too simple to qualify as "protocol",
maybe.

> I would not expect the IANA to honor your request to
> change the intended usage of CRAM-MD5, because entries
> in that registry may only be updated by their owner,
> and your email address is not <[e-mail]>.

They'll figure it out and either forward it, or bounce
it, I sent a copy to iesg@ietf.  The owner can confirm
the fix for this classification, or refuse to fix this.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74Kasx0089184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 13:36:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m74KasD9089183; Mon, 4 Aug 2008 13:36:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74Kapfr089169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 4 Aug 2008 13:36:53 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m74KajpA021561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 16:36:45 -0400 (EDT)
Date: Mon, 04 Aug 2008 16:36:45 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Frank Ellermann <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Message-ID: <[e-mail]>
In-Reply-To: <g6vnus$mt5$[e-mail]>
References:  <[e-mail]> <834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]> <[e-mail]> <[e-mail]> <g6vnus$mt5$[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, August 01, 2008 09:26:25 PM +0200 Frank Ellermann 
<[e-mail]> wrote:

> 2026bis is fortunately no deliverable of the SASL WG, what it's
> supposed to deliver is a DS for CRAM-MD5.  If the SASL WG does
> not more wish to do what it was chartered to do, or maybe never
> intended to do what it was chartered to do, the existing draft
> can be promoted outside of a WG (2821bis + 2822upd just pulled
> that, it is not impossible).  After five years the draft has
> reached its own kind of maturity.  I have implemented its i18n
> example four years ago.  The draft is mentioned in a CRAM-MD5
> implementation and interop report, now also some years old.

You are beginning to sound inflammatory.

I believe there is a consensus in this WG that CRAM-MD5 in its current form 
is not a meechanism we want people to continue to adopt and deploy, and 
that the best course of action is to document what is already deployed, but 
not give it the imprimatur of an Internet standard, and to move forward 
with other mechanisms which have the properties we desire.  I believe this 
consensus is reflected in the Introduction of the current draft.

You can of course argue within the WG that this is not the best course of 
action, at least until the chairs declare that there is a consensus and the 
issue will not be reopened.  You can also participate in the ongoing 
discussion as to what the next charter should look like.  However, I do not 
expect that the IESG will allow you to ignore that consensus and bypass the 
working group by directly submitting individual work that overlaps the area 
of responsibility of an active working group.


> In the request sent to IANA to fix the <quote> erroneous or
> intentional lie <unquote> listing of CRAM-MD5 as "limited use"
> mechanism instead of "common" I've added a fresher reference.

Again, the prhase "erroneous or intentional lie" is inflammatory and 
unnecessary.  It is also incorrect; the listing in the IANA registry of 
CRAM-MD5 as a "LIMITED USE" mechansim is neither a lie (it is not "an 
intentionally false statement" nor even "a statement intended to deceive"), 
nor even incorrect.  The usage column in the registry describes the 
_intended use_ of the mechanism, not how widely deployed it is.  See 
section 7 of RFC4422.

Further, I would not expect the IANA to honor your request to change the 
intended usage of CRAM-MD5, because entries in that registry may only be 
updated by their owner, and your email address is not <[e-mail]>.

The correct way to change the intended usage of CRAM-MD5 is by obtaining 
consensus for such a change in this working group.  If you cannot obtain 
such a consensus, then requesting a change would be inappropriate.

-- 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 m74DNDTl054235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 06:23:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m74DNDq5054234; Mon, 4 Aug 2008 06:23:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74DN87o054223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 4 Aug 2008 06:23:12 -0700 (MST) (envelope-from [e-mail])
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1KQ01W-0006zC-Uh; Mon, 04 Aug 2008 15:23:05 +0200
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: SASL to draft questionnaire
References: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080804:[e-mail]::CMYFrA0esCZW6P6T:CoPe
X-Hashcash: 1:22:080804:[e-mail]::dGDHBsyGzY9m+ofn:STmt
Date: Mon, 04 Aug 2008 15:22:40 +0200
In-Reply-To: <66C88F54C36CF96F0A156AC4@446E7922C82D299DB29D899F> (Chris Newman's message of "Tue, 29 Jul 2008 17:14:32 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> Here's a proposed questionnaire for an implementation report.

Thanks for your initiative!

> I am not volunteering to compile responses to the questions, but I am
> willing to answer these questions for my implementations.

Here is my implementation report.

> RFC 4422 Implementation Questionnaire
> ===============================================
> 0. Contact and Description
> Organization Name:

Simon Josefsson <[e-mail]>.

> Implementation (Software or Service) Name:

See 1.

> 1. Have you implemented SASL and/or SASL mechanism?

Yes.

A. Client authentication for the Emacs SMTP library, see
<http://www.pdc.kth.se/~jas/emacs-rfc2554.html>.

B. A client/server C library in GNU SASL, see
<http://josefsson.org/gsasl/>.

C. Help maintain a client-side SASL library written by Daiki Ueno inside
Gnus (an Emacs-based MUA), see <http://www.gnus.org/>.

D. The client-side SASL handling in imap.el, an Emacs based IMAP
library, see <http://josefsson.org/nnimap/>.

I've probably implemented it a couple of other times, but the above are
the ones that I still actively have an interest in and are widely
deployed and used, at least as far as I can recall when I'm writing
this.

> 2. Which SASL mechanisms have you implemented?

A. CRAM-MD5, PLAIN, LOGIN.

B. PLAIN, CRAM-MD5, DIGEST-MD5, NTLM, GSSAPI, SECURID, EXTERNAL,
ANONYMOUS.

C. CRAM-MD5, DIGEST-MD5, PLAIN, LOGIN, ANONYMOUS, NTLM, SCRAM-MD5.  (Not
implemented by me though, I'm just helping maintaining it inside Gnus.)

D. GSSAPI, KERBEROS4, DIGEST-MD5, CRAM-MD5, LOGIN, ANONYMOUS.

> 3. For how long has it been deployed?

A. 7 years.

B. 6 years.

C. 4 years.

D. 10 years.

> 4. What features have NOT been implemented from SASL?

In A, C, and D SASLprep have not been implemented.

In A, C, and D security layers have not been implemented.  (Although D
uses external tools that may support security layers for
GSSAPI/KERBEROS_V4).

> 5. What features of SASL or SASL mechanisms are problematic for your
> implementation?

Security layers of DIGEST-MD5 have had interop problems.  Other aspects
of DIGEST-MD5 have had interop problems too (such as ", ," quoting and
other minor issues due to its specification complexity).  I would prefer
to see DIGEST-MD5 go away, as it provides negligible benefits over
TLS+CRAM-MD5 or TLS+PLAIN.

In general, security layers are largely under-utilized and I prefer to
depend on TLS and deprecate security layers in SASL.  Users rarely know
or asks about security layers in SASL.  When they do, they are typically
confused and really means TLS.

Only B implements SASLprep.  While SASLprep in B has been used
successfully in deployments, my original complaints about SASLprep's
poor future compatibility are today practical problems that make me
avoid talking actively about it with customers.

I believe the SASL base specification should merely suggest that
mechanisms should be UTF-8 ready and that they have to deal with i18n
issues, and not go into more specifics than that.  Similar to security
technology (HMAC, MD5, Kerberos, etc), internationalization is an
evolving area, and SASL mechanism should be allowed to make sensible
trade-offs in this area.  Customer demand can decide growth.

The semantics of EXTERNAL is under-specified, and the mechanism is
typically only useful when users have good insight into the
administration of both the server and client.  I propose that a revised
EXTERNAL mechanism as specified, that just does channel binding to
another security layer and transfers an authorization identity.

> 6. Please add any other comments you wish to share:

Let me echo Chris's summary, which is the exact same as mine:

I fully support advancement of RFC 4422 to draft status.  It is my
opinion both SASLprep and SASL security layers should be deprecated or
omitted when RFC 4422 advances.  However, I would rather 4422 advances
with those features than have it not advance.

/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 m72AJomd068597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Aug 2008 03:19:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m72AJoNh068596; Sat, 2 Aug 2008 03:19:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m72AJkd5068589 for <[e-mail]>; Sat, 2 Aug 2008 03:19:48 -0700 (MST) (envelope-from [e-mail])
Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm174894b20f; Sat, 02 Aug 2008 18:35:07 +0800
Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmbe488f9cc0; Wed, 30 Jul 2008 00:34:07 +0800
Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 30 Jul 2008 00:34:07 +0800
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF063A6BED; Tue, 29 Jul 2008 09:15:20 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0) id 872C13A6BA5; Tue, 29 Jul 2008 09:15:03 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-ietf-sasl-digest-to-historic-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 29 Jul 2008 09:15:03 -0700 (PDT)
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Reply-To: [e-mail]
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>, <mailto:[e-mail]?subject=subscribe>
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [e-mail] [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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           : Moving DIGEST-MD5 to Historic
	Author(s)       : A. Melnikov
	Filename        : draft-ietf-sasl-digest-to-historic-00.txt
	Pages           : 7
	Date            : 2008-07-29

This memo describes problems with the DIGEST-MD5 Simple
Authentication and Security Layer (SASL) mechanism as specified in
RFC 2831.  It recommends that DIGEST-MD5 to be marked as OBSOLETE in
the IANA Registry of SASL mechanisms, and that RFC 2831 be moved to
Historic status.

Note

A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community.  Discussion
and suggestions for improvement are requested, and should be sent to
[e-mail].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-digest-to-historic-00.txt

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

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

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

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


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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m71JPg0D018847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 12:25:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m71JPgG4018846; Fri, 1 Aug 2008 12:25:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m71JPVqV018835 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 1 Aug 2008 12:25:39 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KP0Fj-0006nO-Cf for [e-mail]; Fri, 01 Aug 2008 19:25:27 +0000
Received: from 212.82.251.150 ([212.82.251.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 01 Aug 2008 19:25:27 +0000
Received: from nobody by 212.82.251.150 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 01 Aug 2008 19:25:27 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  "Frank Ellermann" <[e-mail]>
Subject:  Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date:  Fri, 1 Aug 2008 21:26:25 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 95
Message-ID: <g6vnus$mt5$[e-mail]>
References:  <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]> <[e-mail]> <[e-mail]>
Reply-To:  "Frank Ellermann" <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:  quoted-printable
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: 212.82.251.150
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
Cc: [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>

Kurt Zeilenga wrote on the SASL list:

> 1) revise the CRAM-MD5 specification, resolving known technical =20
> issues, such that it is suitable for progression (eventually all
> the way to Internet Standard) on the Standards Track,
> 2) seek a waiver from the IESG of certain requirements placed upon =20
> SASL mechanism specifications (such as RFC 4422 requirement that
> mechanism specifications detail how character data inputs to
> cryptographic functions be precisely specified to ensure
> interoperability), or
> 3) documenting existing CRAM-MD5 practice in an Informational =20
> document, noting the known technical issues.
=20
> Consensus has been, and continued to be, that fixing known technical
> issues would be too disruptive to existing deployments (which as you =20
> note are quite significant).  With this consensus, the third path =20
> seems quite appropriate as seems to make no sense to progress a =20
> document on the standard track that you wouldn't put on the standards  =

> track if considered anew.

Objection:  There are various protocols such as SMTP and HTTP that
would be not "put on the standards track if considered anew" as is,
where they disagree with RFC 2277 and UTF-8.  HTTP has a charming
default Latin-1, while at it overriding MIME text/* in weird ways.

This is a red herring.  RFC 2026 demands maturity, IMO it does not
ask "would you do this again exactly as is now, six years later ?".

RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII.
If implementations do something that is not specified it is their
problem.  If they ignored RFC 2277 and didn't pick UTF-8 for their
choice of "something" they also own the pieces of whatever breaks.

Actually it is now eleven years later, but CRAM-MD5 drafts spent
five years in SASL deliberations, that is no problem in RFC 2195.

> given the WG consensus not to disruptive to deployments of
> CRAM-MD5, the intent seems to be never to revise the=20
> specification to met the requirements.

 [quoting the Charter]
| This group will deliver revised Technical Specifications suitable for
| consideration as Draft Standards for the following SASL mechanisms:
| ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will
| be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon,
| draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and
| draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt.

CRAM-MD5 is about as simple as it can get, and as RFC 2195 does
not mention what to do with the 8th bit the normal approach in
RFC 2277 "let's take UTF-8" will work as expected.  Limiting it
to whatever other SASL mechanisms do (at the moment *in theory*=20
SASLprep) is no issue, US-ASCII is a proper subset of SASLprep.

In practice RFC 5198 might be a better approach, and once again
US-ASCII is a proper subset of Net-UTF8 (NFC with minor twists).

> It seems inappropriate to keep such a specification on the
> standards track.

2026bis is fortunately no deliverable of the SASL WG, what it's
supposed to deliver is a DS for CRAM-MD5.  If the SASL WG does
not more wish to do what it was chartered to do, or maybe never
intended to do what it was chartered to do, the existing draft
can be promoted outside of a WG (2821bis + 2822upd just pulled
that, it is not impossible).  After five years the draft has
reached its own kind of maturity.  I have implemented its i18n
example four years ago.  The draft is mentioned in a CRAM-MD5
implementation and interop report, now also some years old.

In the request sent to IANA to fix the <quote> erroneous or
intentional lie <unquote> listing of CRAM-MD5 as "limited use"
mechanism instead of "common" I've added a fresher reference.

> Another challenge is that the RFC 2026 specifically warns =20
> deployments of Proposed Standard specifications of the
> likelihood that subsequent revision will be disruptive to
> deployers

Yes, if some implementation insists on say KOI8-R instead of
an appropriate style of UTF-8 it owns the pieces, see above.
This was not specified, above a broad hint at RFC 822, and
there is no KOI8-R in RFC 822.

> I do believe there are other requirements.

I doubt it.  CRAM-MD5 is at a similar level of complexity as
PLAIN adding HMAC.  Being better than "pseudo-PLAIN" (PLAIN
outside of SSL), or APOP, or "LOGIN" is the whole purpose of
CRAM-MD5.  That CRAM-MD5 is also "better" than DIGEST-MD5 in
a certain sense was no design goal, it just happened as side
effect of KISS.

 Frank



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m719tCEw074997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 02:55:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m719tCiE074996; Fri, 1 Aug 2008 02:55:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m719tB7I074989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 1 Aug 2008 02:55:12 -0700 (MST) (envelope-from [e-mail])
Received: from nomad.meeting.ietf.org ([130.129.21.36]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m719t82l050366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2008 09:55:10 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Lyndon Nerenberg <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v928.1)
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt
Date: Fri, 1 Aug 2008 10:55:06 +0100
References: <[e-mail]><834E1C1F0C308FD6EF2E133A@446E7922C82D299DB29D899F> <[e-mail]> <g6k7cq$3iv$[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.928.1)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I see the WG as having needs to choose between three possible  
approaches:
1) revise the CRAM-MD5 specification, resolving known technical  
issues, such that it is suitable for progression (eventually all the  
way to Internet Standard) on the Standards Track,
2) seek a waiver from the IESG of certain requirements placed upon  
SASL mechanism specifications (such as RFC 4422
requirement that mechanism specifications detail how character data  
inputs to cryptographic functions be precisely specified to ensure
interoperability), or
3) documenting existing CRAM-MD5 practice in an Informational  
document, noting the known technical issues.

Consensus has been, and continued to be, that fixing known technical  
issues would be too disruptive to existing deployments (which as you  
note are quite significant).  With this consensus, the third path  
seems quite appropriate as seems to make no sense to progress a  
document on the standard track that you wouldn't put on the standards  
track if considered anew.

It seems to me that what you and others seek is an IESG waiver from  
various requirements placed this technical specification.  It is  
unclear to me whether the IESG which, if any, requirements the IESG  
might be willing to waive in this case.   To to able to even consider  
granting a waiver, they would from us a statement of the specific  
requirements we wish to have waived and why we believe the waiver is  
justified.   I suspect this approach would face a number of challenges  
and is likely to fail.   In particular, given the WG consensus not to  
disruptive to deployments of CRAM-MD5, the intent seems to be never to  
revise the specification to met the requirements.  As such, the  
specification would ever be suitable for Draft (or better) status.  It  
seems inappropriate to keep such a specification on the standards  
track.  Another challenge is that the RFC 2026 specifically warns  
deployments of Proposed Standard specifications of the likelihood that  
subsequent revision will be disruptive to deployers and hence a  
request for waivers based upon such disruption is weak at best.   
Anyways, I ask that those who advocate that certain requirements be  
waived prepare text detail why they should be waived.

I do think it reasonable for those believing the specification fails  
to met requirements placed upon it, enumerate those requirements.   
With that in mind, one requirement I see (off hand) failing to met is  
RFC 4422 mandatory requirement that SASL mechanisms specifications  
precisely specify how character data is to be prepared for input to  
cryptographic to ensure interoperability between implementations of  
the specification.  I do believe there are other requirements.  I  
encourage others to detail them on the list.

I note that little work is needed to accomplish 3 (make the changes  
recently discussed on the list).   2 requires a some amount of work:  
namely documenting the requirements to be waived and why.  1 has no  
support for actually making the changes required under this approach.

-- Kurt