Re: Consensus call: the fate of CRAM-MD5

[Alexey Melnikov <[e-mail]>]

Kurt Zeilenga wrote:

> After some discussion with various others, I make the following  
> suggestion:
>
> I suggest we defer the question of whether RFC 2195 should be moved 
> to  Historic (by publication of a draft such as what I offered) until 
> 3-6  months after the publication of SCRAM RFC.   It is my hope that 
> this  would allow adequate adoption of SCRAM to sway additional 
> participants  to support obsoleting RFC 2195, and hence allow at least 
> a rough  consensus to be achieved to moving RFC 2195 to historic.

Agreed.

> I would strongly object to hinging the publication of SCRAM on any  
> question about CRAM-MD5 (or DIGEST-MD5) status.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QMni6v011592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 15:49:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QMnicN011590; Thu, 26 Mar 2009 15:49:44 -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 n2QMnW3R011561 for <[e-mail]>; Thu, 26 Mar 2009 15:49:43 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 26 Mar 2009 22:49:31 +0000
Message-ID: <[e-mail]>
Date: Thu, 26 Mar 2009 15:49:12 -0700
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Kurt Zeilenga <[e-mail]>
CC: [e-mail]
Subject: Re: Consensus call: the fate of CRAM-MD5
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> After some discussion with various others, I make the following  
> suggestion:
>
> I suggest we defer the question of whether RFC 2195 should be moved 
> to  Historic (by publication of a draft such as what I offered) until 
> 3-6  months after the publication of SCRAM RFC.   It is my hope that 
> this  would allow adequate adoption of SCRAM to sway additional 
> participants  to support obsoleting RFC 2195, and hence allow at least 
> a rough  consensus to be achieved to moving RFC 2195 to historic.

Agreed.

> I would strongly object to hinging the publication of SCRAM on any  
> question about CRAM-MD5 (or DIGEST-MD5) status.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2QKCY2F001863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 13:12:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2QKCY0b001862; Thu, 26 Mar 2009 13:12: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 n2QKCWMj001851 for <[e-mail]>; Thu, 26 Mar 2009 13:12:32 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-55e7.meeting.ietf.org ((unknown) [130.129.85.231])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Thu, 26 Mar 2009 20:12:31 +0000
X-SMTP-Protocol-Errors: NORDNS
Cc: Tom Yu <[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: Consensus call: the fate of CRAM-MD5
Date: Thu, 26 Mar 2009 13:12:27 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mar 24, 2009, at 8:39 AM, Kurt Zeilenga wrote:
> I favor the SASL WG doing no more CRAM-MD5 work.  That is, I favor  
> simply all mention of CRAM-MD5 from the WG charter.

s/simply all/simply removing all/




After some discussion with various others, I make the following  
suggestion:

I suggest we defer the question of whether RFC 2195 should be moved to  
Historic (by publication of a draft such as what I offered) until 3-6  
months after the publication of SCRAM RFC.   It is my hope that this  
would allow adequate adoption of SCRAM to sway additional participants  
to support obsoleting RFC 2195, and hence allow at least a rough  
consensus to be achieved to moving RFC 2195 to historic.

I would strongly object to hinging the publication of SCRAM on any  
question about CRAM-MD5 (or DIGEST-MD5) status.

-- 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 n2OMbxEF041895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 15:37:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OMbxeK041894; Tue, 24 Mar 2009 15:37:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OMblk1041885 for <[e-mail]>; Tue, 24 Mar 2009 15:37:58 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]> for <[e-mail]>; Tue, 24 Mar 2009 22:38:36 +0000
Subject: TLS endpoint channel bindings in SCRAM
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 24 Mar 2009 22:37:37 +0000
From: Dave Cridland <[e-mail]>
To: <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Having carefully examined the tls-server-end-point channel binding,  
I've a bit of a concern.

One of the sticking points of the tls-unique channel binding is how  
easy it is to get at the data - OpenSSL provides an API, however it's  
often not exposed to language bindings such as Python, etc, and other  
TLS implementations may not provide it at all.

I can't find any way of getting at the on-wire representation of the  
server's certificate, and I can't immediately find a way of  
discovering which hash algorithm to use, either, in the vast majority  
of bindings.

So rather than expect all TLS implementations and bindings to change,  
I'd like to propose an alternate binding, for use where the server's  
certificate is an X.509v3 one.

Specifically, I'd like to use a fixed hash algorithm over the  
DER-encoded form of the certificate - I'll call this  
"tls-x509-end-point"

The DER form of the certificate is readily available through most  
bindings, in many cases in a single call, and gives exactly  
equivalent hash-input as the on-wire format, which is very likely  
[but not mandated, as far as I can find] to be DER anyway.

Fixing a hash algorithm simply makes this even easier - the current  
channel binding uses SHA-256 as a "minimum hash", I'd prefer to use  
SHA-1, as we're certain to have it for SCRAM.

Finally, I'd propose that SCRAM mandates support for the  
'tls-x509-end-point' channel binding for the applicable cases as a  
reasonable fallback when support for the more flexible and  
future-proof tls-server-end-point binding is not available.

Now I'll wait to get shot down in flames. :-)

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OKGHJi034580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 13:16:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OKGHST034579; Tue, 24 Mar 2009 13:16:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n2OKG5MY034572 for <[e-mail]>; Tue, 24 Mar 2009 13:16:15 -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 n2OKG5iD002888 for <[e-mail]>; Tue, 24 Mar 2009 20:16:05 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2OKG4Sq050170 for <[e-mail]>; Tue, 24 Mar 2009 14:16:04 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2OJTHF8003996; Tue, 24 Mar 2009 14:29:17 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2OJTCRp003995; Tue, 24 Mar 2009 14:29:12 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 24 Mar 2009 14:29:12 -0500
From: Nicolas Williams <[e-mail]>
To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= <[e-mail]>
Cc: Tony Finch <[e-mail]>, Chris Newman <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Inclusion of service name or URI in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 24, 2009 at 12:04:01PM -0700, Love Hörnquist Åstrand wrote:
> "URI" parameter wont affect sharing the authentication database.
> 
> It will stop passing of authentication exchanges between unrelated  
> "domains", aka MITM attacks.

Not if you have neither: a) security layers, b) a secure channel to bind
to and channel binding.

We've got consensus for ditching security layers.  So that leaves (b),
which you claim won't happen.

If we want to solve this particular problem then apps MUST use one of
security layers or channel binding.

Which means we must pick one of those solutions and specify them.  If we
specify both then we're likely to run into an interop problem: clients
that only support (a) or (b) not talking to servers that only support
(b) or (a).

That said, adding a "URI" parameter will prevent misdirection attacks
(active attacks where the attacker is nonetheless not an MITM), but only
if the server you're redirected to is not in league with the attacker.

Given some of the SASL application implementor comments that we've seen
on the list it's unlikely that we'll get consensus for security layers.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OJvRIK033375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 12: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 n2OJvRp9033374; Tue, 24 Mar 2009 12:57:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OJvGNw033361 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 24 Mar 2009 12:57:27 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2OJvGNr028357 for <[e-mail]>; Tue, 24 Mar 2009 19:57:16 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2OJvFFp035748 for <[e-mail]>; Tue, 24 Mar 2009 13:57:15 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2OJeYTO004009; Tue, 24 Mar 2009 14:40:34 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2OJeY0b004008; Tue, 24 Mar 2009 14:40:34 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 24 Mar 2009 14:40:34 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail]
Subject: Re: New SCRAM and GS2 I-Ds
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 24, 2009 at 06:13:19PM +0000, Dave Cridland wrote:
> On Mon Mar 23 16:13:30 2009, Nicolas Williams wrote:
> >
> >New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
> >been posted.
> 
> A couple of nits - the ABNF has:
> 
>     ;;cbind-type    = value
>     ;;cbind-input   = gs2-header [ value ":" cbind-data ]
>     channel-binding = "c=" base64
>                       ;; base64 encoding of cbind-input
> 
> I think the "value" should be "cbind-type", and I think cbind-type =  
> "tls-unique" / value would be better to make it clear what kind of  
> stuff is expected there.

Ah, yes, this is a typo.  I need to define cbind-data (*OCTET) and fix
cbind-input:

     ;;cbind-data    = *OCTET
     ;;cbind-type    = value
     ;;cbind-input   = gs2-header [ cbind-type ":" cbind-data ]

> Also, I wouldn't comment these out.
> 
>     client-final-message-without-proof =
>                       [channel-binding ","] nonce [","
>                       extensions]
> 
> Channel binding (c=) is no longer optional, so this needs updating.

Good catch, thanks!

> Otherwise, i think I'm up to date with these changes, and it really  
> didn't take long, so that's great.

Awesome.

Back to your comments in the room, we can compress the CB flag by
removing one of its possible values since it'd be possible to
unambiguously know what that case would be.  I used that trick to remove
the RFC2743 initial context token header compression flag in the case of
standard GSS mechs (before: "T" or "F"; now: "" or "F").  But I don't
think it's worth it.

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 n2OJ4P91029700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 12:04:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OJ4OU6029699; Tue, 24 Mar 2009 12:04:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OJ4Chw029676 for <[e-mail]>; Tue, 24 Mar 2009 12:04:23 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id EC4BF14D7CC; Tue, 24 Mar 2009 20:04:10 +0100 (CET)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0hCWvodLCwqP; Tue, 24 Mar 2009 20:04:10 +0100 (CET)
Received: from [IPv6:2001:df8::80:21e:c2ff:fec5:249f] (unknown [IPv6:2001:df8:0:80:21e:c2ff:fec5:249f]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 2658D14C0F6; Tue, 24 Mar 2009 20:04:04 +0100 (CET)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1051)
Subject: Re: Inclusion of service name or URI in SCRAM
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 24 Mar 2009 12:04:01 -0700
Cc: Chris Newman <[e-mail]>, "[e-mail]" <[e-mail]>
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Tony Finch <[e-mail]>
X-Mailer: Apple Mail (2.1051)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

24 mar 2009 kl. 10:02 skrev Tony Finch:

>> I found the "URI" parameter in digest confusing and a deployment  
>> barrier. What
>> does the hostname in the "URI" mean?  What sort of checks should be  
>> performed
>> on it?  What if the URI doesn't include a hostname?  Can a user  
>> have multiple
>> passwords on the same host and what are the client UI implications  
>> for that?
>
> There isn't an smtp URI scheme, and mailto: doesn't have a field for  
> the
> message submission server hostname.
>
> Will the lack of a URI parameter provide any advantages when multiple
> parallel services share the same authentication database (e.g. smtp,  
> imap,
> ldap, xmpp, ...)

"URI" parameter wont affect sharing the authentication database.

It will stop passing of authentication exchanges between unrelated  
"domains", aka MITM attacks.

Love




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OIDZve026888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 11:13:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OIDZK3026887; Tue, 24 Mar 2009 11:13:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OIDXbe026880 for <[e-mail]>; Tue, 24 Mar 2009 11:13:34 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Tue, 24 Mar 2009 18:14:18 +0000
Subject: Re: New SCRAM and GS2 I-Ds
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 24 Mar 2009 18:13:19 +0000
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon Mar 23 16:13:30 2009, Nicolas Williams wrote:
> 
> New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
> been posted.

A couple of nits - the ABNF has:

     ;;cbind-type    = value
     ;;cbind-input   = gs2-header [ value ":" cbind-data ]
     channel-binding = "c=" base64
                       ;; base64 encoding of cbind-input

I think the "value" should be "cbind-type", and I think cbind-type =  
"tls-unique" / value would be better to make it clear what kind of  
stuff is expected there.

Also, I wouldn't comment these out.

     client-final-message-without-proof =
                       [channel-binding ","] nonce [","
                       extensions]

Channel binding (c=) is no longer optional, so this needs updating.

Otherwise, i think I'm up to date with these changes, and it really  
didn't take long, so that's great.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OH32VZ022378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 10:03:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OH32TN022377; Tue, 24 Mar 2009 10:03:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OH2oU8022355 for <[e-mail]>; Tue, 24 Mar 2009 10:03:01 -0700 (MST) (envelope-from [e-mail])
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40662) by ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1LmA1Z-0002xN-JS (Exim 4.70) (return-path <[e-mail]>); Tue, 24 Mar 2009 17:02:49 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LmA1Z-0004WQ-0Z (Exim 4.67) (return-path <[e-mail]>); Tue, 24 Mar 2009 17:02:49 +0000
Date: Tue, 24 Mar 2009 17:02:49 +0000
From: Tony Finch <[e-mail]>
X-X-Sender: [e-mail]
To: Chris Newman <[e-mail]>
cc: [e-mail]
Subject: Re: Inclusion of service name or URI in SCRAM
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 23 Mar 2009, Chris Newman wrote:
>
> I found the "URI" parameter in digest confusing and a deployment barrier. What
> does the hostname in the "URI" mean?  What sort of checks should be performed
> on it?  What if the URI doesn't include a hostname?  Can a user have multiple
> passwords on the same host and what are the client UI implications for that?

There isn't an smtp URI scheme, and mailto: doesn't have a field for the
message submission server hostname.

Will the lack of a URI parameter provide any advantages when multiple
parallel services share the same authentication database (e.g. smtp, imap,
ldap, xmpp, ...)

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OFwUSH017636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 08:58:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OFwUxK017635; Tue, 24 Mar 2009 08:58: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-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 n2OFwJgG017621 for <[e-mail]>; Tue, 24 Mar 2009 08:58:30 -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 n2OFwJ6R011209 for <[e-mail]>; Tue, 24 Mar 2009 15:58:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2OFwJHG044880 for <[e-mail]>; Tue, 24 Mar 2009 09:58:19 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2OFfZdq003670; Tue, 24 Mar 2009 10:41:35 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2OFfYEk003669; Tue, 24 Mar 2009 10:41:34 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 24 Mar 2009 10:41:34 -0500
From: Nicolas Williams <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: [e-mail]
Subject: Re: New SCRAM and GS2 I-Ds
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 24, 2009 at 03:34:57PM +0000, Dave Cridland wrote:
> On Mon Mar 23 16:13:30 2009, Nicolas Williams wrote:
> >New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
> >been posted.
> >
> >These reflect the new GS2 design.
> 
> This looks fine.

Great!

> However, I'm bewildered by section 6 in the new draft, a bit.
> 
> 1) Can you explain the difference between the channel binding cases?  
> If I say "n", I don't include the "c=" data, because I can't do it.  

You still include c= because that is used to protect the "n" and
optional authzid from the GS2 header.  But the c= will not include any
channel binding data for an external channel.

> Fine. If I say "y", then I *can* include the "c=" data, and the  
> server could then take it into account for the hashes, but would be  
> unable to verify it. But yet I don't, I have to leave it out. Why?

"y" means not that the client did include channel binding data for the
external channel, but that it could have -- and that it didn't because
it thought the server did not support channel binding.

If the choice of flag values, "n", "y" and "p" are confusing we can
always pick new ones.

> 2) "if the channel was established using a server certificate to  
> authenticate the server" - does that mean that if the server  
> presented a certificate which I cannot trust, I should use  
> tls-unique? Or what? Why would I want to be using  
> tls-server-end-point - what does this gain?

Say the server has a self-signed cert, and it's not been pre-shared to
the client.  Then the server is effectively anonymous.  Now, if the
client sees the server cert that server used, then there cannot be an
MITM in at the TLS layer, but if it sees a different cert than the
server used, then the client must be connected to an MITM.  Because
demonstrating that the client saw the same server cert as the server
used is sufficient to rule out an MITM we can use the server's cert as
the channel binding for TLS.  Unique channel bindings could be used too,
but end-point channel bindings play better with TLS concentrators,
therefore we prefer them.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OFtpmv017392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 08:55:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OFtpQR017391; Tue, 24 Mar 2009 08:55:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OFtntG017383 for <[e-mail]>; Tue, 24 Mar 2009 08:55:50 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 24 Mar 2009 15:55:48 +0000
Message-ID: <[e-mail]>
Date: Tue, 24 Mar 2009 08:55:25 -0700
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Dave Cridland <[e-mail]>
CC: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: New SCRAM and GS2 I-Ds
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland wrote:

> On Mon Mar 23 16:13:30 2009, Nicolas Williams wrote:
>
>> New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
>> been posted.
>>
>> These reflect the new GS2 design.
>
> This looks fine.
>
> However, I'm bewildered by section 6 in the new draft, a bit.
>
> 1) Can you explain the difference between the channel binding cases?  
> If I say "n", I don't include the "c=" data, because I can't do it.  
> Fine. If I say "y", then I *can* include the "c=" data, and the  
> server could then take it into account for the hashes, but would be  
> unable to verify it. But yet I don't, I have to leave it out. Why?

No, my understanding is that c= is always included, but it might not 
contain the actual channel binding in some cases.

> 2) "if the channel was established using a server certificate to  
> authenticate the server" - does that mean that if the server  
> presented a certificate which I cannot trust, I should use  
> tls-unique? Or what? Why would I want to be using  
> tls-server-end-point - what does this gain?

Good question.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OFde8G016168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 08:39:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OFdexj016167; Tue, 24 Mar 2009 08:39: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 n2OFddee016159 for <[e-mail]>; Tue, 24 Mar 2009 08:39:39 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-55e7.meeting.ietf.org ((unknown) [130.129.85.231])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 24 Mar 2009 15:39:38 +0000
X-SMTP-Protocol-Errors: NORDNS
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Tom Yu <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: Consensus call: the fate of CRAM-MD5
Date: Tue, 24 Mar 2009 08:39:33 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I favor the SASL WG doing no more CRAM-MD5 work.  That is, I favor  
simply all mention of CRAM-MD5 from the WG charter.

-- 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 n2OFZSpV015855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 08:35:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OFZSpw015854; Tue, 24 Mar 2009 08:35:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OFZHhF015842 for <[e-mail]>; Tue, 24 Mar 2009 08:35:28 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Tue, 24 Mar 2009 15:35:58 +0000
Subject: Re: New SCRAM and GS2 I-Ds
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 24 Mar 2009 15:34:57 +0000
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon Mar 23 16:13:30 2009, Nicolas Williams wrote:
> New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
> been posted.
> 
> These reflect the new GS2 design.

This looks fine.

However, I'm bewildered by section 6 in the new draft, a bit.

1) Can you explain the difference between the channel binding cases?  
If I say "n", I don't include the "c=" data, because I can't do it.  
Fine. If I say "y", then I *can* include the "c=" data, and the  
server could then take it into account for the hashes, but would be  
unable to verify it. But yet I don't, I have to leave it out. Why?

2) "if the channel was established using a server certificate to  
authenticate the server" - does that mean that if the server  
presented a certificate which I cannot trust, I should use  
tls-unique? Or what? Why would I want to be using  
tls-server-end-point - what does this gain?

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OEQJS5010855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 07:26:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2OEQJB2010854; Tue, 24 Mar 2009 07:26:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OEQIuo010847 for <[e-mail]>; Tue, 24 Mar 2009 07:26:18 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 24 Mar 2009 14:26:16 +0000
Message-ID: <[e-mail]>
Date: Tue, 24 Mar 2009 07:25:58 -0700
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: Tom Yu <[e-mail]>, [e-mail]
Subject: Re: Consensus call: the fate of CRAM-MD5
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Tom Yu <[e-mail]> writes:
>
>  
>
>>Based on earlier mail from Lyndon and Alexey, I am initiating a
>>consensus call on the following points, which I hope are not
>>contentious, as I believe that they express the existing desires of
>>the Working Group:
>>
>>* Abandon work on draft-ietf-sasl-crammd5, removing it from the WG
>>  work list.  (de facto already done)
>>
>>* Leave the status of RFC 2195 (Proposed Standard) unchanged.
>>
>>* Adopt the SCRAM family as the successor to CRAM-MD5.
>>
>>* New work item: produce an Informational RFC documenting existing
>>  issues with CRAM-MD5.  This document could be based on
>>  draft-zeilenga-sasl-crammd5.
>>
>>* At some point in the future, probably after SCRAM is finished, move
>>  CRAM-MD5 to Historic status.
>>
>>Please comment before April 3.  We can discuss this at tomorrow's WG
>>session if necessary, but I do not want it to occupy a lot of session
>>time without good reason.
>>    
>>
>I agree.
>
>I believe the third point may be contentious, given John Kleinsin's
>comment at the appsarea meeting.  I don't think we need a decision that
>SCRAM will replace CRAM-MD5.
>
I agree.

>If we are successful, SCRAM will replace
>CRAM-MD5 in deployments.  If this does not succeed, it does not help
>that we say that SCRAM really does replace CRAM-MD5.
>
>I would support the plan without the third point too.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2OECXsB010144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 07: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 n2OECXDp010143; Tue, 24 Mar 2009 07: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 n2OECJi1010113 for <[e-mail]>; Tue, 24 Mar 2009 07:12:30 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 24 Mar 2009 14:12:18 +0000
Message-ID: <[e-mail]>
Date: Tue, 24 Mar 2009 06:26:36 -0700
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Newman <[e-mail]>
CC: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: deriving client and server key
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <B5048FA51FC6B2F3E0585454@446E7922C82D299DB29D899F>
In-Reply-To: <B5048FA51FC6B2F3E0585454@446E7922C82D299DB29D899F>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman wrote:

> --On February 23, 2009 8:59:44 -0800 Love H=C3=B6rnquist =C3=85strand=20
> <[e-mail]> wrote:
>
>> Right now the client and server key differences is:
>>
>> ClientKey =3D H(SaltedPassword)
>> ServerKey =3D HMAC(SaltedPassword, salt)
>>
>> Why are the derived by two different methods ? (why not XKey =3D
>> HMAC(SaltedKey, "X key")
>
> I just realized I hadn't mentioned publicly that I think this would be=20
> a good change.
>
> Specifically:
>
> ClientKey =3D HMAC(SaltedPassword, "Client Key")
> ServerKey =3D HMAC(SaltedPassword, "Server Key")
>
> I think this actually makes the algorithm description a bit easier to=20
> understand.  What do others think?

I don't really care. I've already implemented the old way, but changing=20
my implementation wouldn't be difficult.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O9EqWt087218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 02:14:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2O9EqEH087217; Tue, 24 Mar 2009 02:14:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O9EfJX087190 for <[e-mail]>; Tue, 24 Mar 2009 02:14:51 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 1B1AF4AC22; Tue, 24 Mar 2009 10:14:40 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1237886078-99745-99744/6/16 for [e-mail]; Tue, 24 Mar 2009 10:14:38 +0100
Message-Id: <[e-mail]>
Date: Tue, 24 Mar 2009 10:13:36 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Consensus call: the fate of CRAM-MD5
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu writes:
> Based on earlier mail from Lyndon and Alexey, I am initiating a 
> consensus call on the following points, which I hope are not 
> contentious, as I believe that they express the existing desires of 
> the Working Group:

Excellent plan overall.

> * Adopt the SCRAM family as the successor to CRAM-MD5.

What does this mean? If it means "replace the bad GS2 stuff with simpler 
GS2 stuff", fine. Write a milestone for March 2009 and mark it as done. 
It it also means "consider RAM-only implementers an important audience 
for the SCRAM RFC", then you will hear no protest from me.

> * New work item: produce an Informational RFC documenting existing 
> issues with CRAM-MD5.

... which includes (should include) notes about any known differences 
between 2195 and deployed reality. I know of only one: Some 
implementations use more entropy than the specified 11 bits when 
generating challenges.

...

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O7UKik080382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 00:30:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2O7UKAx080381; Tue, 24 Mar 2009 00:30:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O7UIAb080371 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 24 Mar 2009 00:30:19 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lm15V-0004Xk-4v; Tue, 24 Mar 2009 08:30:18 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: New SCRAM and GS2 I-Ds
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090324:[e-mail]::8S/TXDN+PC4GUuTE:GQnQ
X-Hashcash: 1:22:090324:[e-mail]::VghzxXX6M2btq5a0:BNJU
Date: Tue, 24 Mar 2009 08:30:15 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 23 Mar 2009 11:13:30 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
> been posted.

A diff for GS2 is available here:

http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-sasl-gs2-11.txt

/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 n2O7Ld0O079792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 00:21:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2O7LdpN079791; Tue, 24 Mar 2009 00:21:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O7LZBo079783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 24 Mar 2009 00:21:37 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lm0x1-0004XY-Rs; Tue, 24 Mar 2009 08:21:32 +0100
From: Simon Josefsson <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: [e-mail]
Subject: Re: Consensus call: the fate of CRAM-MD5
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090324:[e-mail]::5XHaDDCN0PHsVvfY:Kgd2
X-Hashcash: 1:22:090324:[e-mail]::S5xEkepg0PXoLAKz:QPjy
Date: Tue, 24 Mar 2009 08:21:28 +0100
In-Reply-To: <[e-mail]> (Tom Yu's message of "Mon, 23 Mar 2009 22:33:51 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu <[e-mail]> writes:

> Based on earlier mail from Lyndon and Alexey, I am initiating a
> consensus call on the following points, which I hope are not
> contentious, as I believe that they express the existing desires of
> the Working Group:
>
> * Abandon work on draft-ietf-sasl-crammd5, removing it from the WG
>   work list.  (de facto already done)
>
> * Leave the status of RFC 2195 (Proposed Standard) unchanged.
>
> * Adopt the SCRAM family as the successor to CRAM-MD5.
>
> * New work item: produce an Informational RFC documenting existing
>   issues with CRAM-MD5.  This document could be based on
>   draft-zeilenga-sasl-crammd5.
>
> * At some point in the future, probably after SCRAM is finished, move
>   CRAM-MD5 to Historic status.
>
> Please comment before April 3.  We can discuss this at tomorrow's WG
> session if necessary, but I do not want it to occupy a lot of session
> time without good reason.

I agree.

I believe the third point may be contentious, given John Kleinsin's
comment at the appsarea meeting.  I don't think we need a decision that
SCRAM will replace CRAM-MD5.  If we are successful, SCRAM will replace
CRAM-MD5 in deployments.  If this does not succeed, it does not help
that we say that SCRAM really does replace CRAM-MD5.

I would support the plan without the third point too.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O7G1vP079497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 00:16:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2O7G1LD079496; Tue, 24 Mar 2009 00:16:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O7FlKw079462 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 24 Mar 2009 00:15:59 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lm0rQ-0004XO-63; Tue, 24 Mar 2009 08:15:45 +0100
From: Simon Josefsson <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: deriving client and server key
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <B5048FA51FC6B2F3E0585454@446E7922C82D299DB29D899F>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090324:[e-mail]::6BoXlpgyRngn5nMp:5RL7
X-Hashcash: 1:22:090324:[e-mail]::2ZWv9tr/AqMB4RGX:61hl
X-Hashcash: 1:22:090324:[e-mail]::GJooebH58+iREi5s:KOY5
X-Hashcash: 1:22:090324:[e-mail]::/EpsPZgkHzglV8If:R6CC
Date: Tue, 24 Mar 2009 08:15:42 +0100
In-Reply-To: <B5048FA51FC6B2F3E0585454@446E7922C82D299DB29D899F> (Chris Newman's message of "Mon, 23 Mar 2009 13:13:56 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman <[e-mail]> writes:

> --On February 23, 2009 8:59:44 -0800 Love Hörnquist Åstrand
> <[e-mail]> wrote:
>> Right now the client and server key differences is:
>>
>> ClientKey = H(SaltedPassword)
>> ServerKey = HMAC(SaltedPassword, salt)
>>
>> Why are the derived by two different methods ? (why not XKey =
>> HMAC(SaltedKey, "X key")
>
> I just realized I hadn't mentioned publicly that I think this would be
> a good change.
>
> Specifically:
>
> ClientKey = HMAC(SaltedPassword, "Client Key")
> ServerKey = HMAC(SaltedPassword, "Server Key")
>
> I think this actually makes the algorithm description a bit easier to
> understand.  What do others think?

I had the same thought when I reviewed the protocol, but didn't bring it
up before.  I would support this change.  I think it actually makes the
protocol stronger, because HMAC's have different cryptographic
properties than hashes.  For example, HMAC-MD5 is still secure even
though MD5 is considered broken.  That is a good property to have in a
protocol like this, especially when we chose SHA-1 for the hash.

/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 n2O2Y6ar064676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 19:34:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2O2Y6WE064675; Mon, 23 Mar 2009 19:34:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2O2XsbZ064650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 23 Mar 2009 19:34:05 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n2O2XqCv026574 for <[e-mail]>; Mon, 23 Mar 2009 22:33:53 -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 n2O2XpX3008959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 23 Mar 2009 22:33:52 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n2O2XpXo012726; Mon, 23 Mar 2009 22:33:51 -0400 (EDT)
To: [e-mail]
Subject: Consensus call: the fate of CRAM-MD5
From: Tom Yu <[e-mail]>
Date: Mon, 23 Mar 2009 22:33:51 -0400
Message-ID: <[e-mail]>
Lines: 22
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>

Based on earlier mail from Lyndon and Alexey, I am initiating a
consensus call on the following points, which I hope are not
contentious, as I believe that they express the existing desires of
the Working Group:

* Abandon work on draft-ietf-sasl-crammd5, removing it from the WG
  work list.  (de facto already done)

* Leave the status of RFC 2195 (Proposed Standard) unchanged.

* Adopt the SCRAM family as the successor to CRAM-MD5.

* New work item: produce an Informational RFC documenting existing
  issues with CRAM-MD5.  This document could be based on
  draft-zeilenga-sasl-crammd5.

* At some point in the future, probably after SCRAM is finished, move
  CRAM-MD5 to Historic status.

Please comment before April 3.  We can discuss this at tomorrow's WG
session if necessary, but I do not want it to occupy a lot of session
time without good reason.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NNvSji056852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 16:57:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NNvSxt056851; Mon, 23 Mar 2009 16:57:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NNvG2T056835 for <[e-mail]>; Mon, 23 Mar 2009 16:57:27 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 6CC991557D7; Tue, 24 Mar 2009 00:57:15 +0100 (CET)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ivLldmquYeLH; Tue, 24 Mar 2009 00:57:09 +0100 (CET)
Received: from [IPv6:2001:df8::48:21f:f3ff:fe4d:e8cc] (unknown [IPv6:2001:df8:0:48:21f:f3ff:fe4d:e8cc]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 915701557D6; Tue, 24 Mar 2009 00:57:05 +0100 (CET)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1051)
Subject: Re: Inclusion of service name or URI in SCRAM
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Mon, 23 Mar 2009 16:57:03 -0700
Cc: "[e-mail]" <[e-mail]>
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
References: <[e-mail]>
To: Chris Newman <[e-mail]>
X-Mailer: Apple Mail (2.1051)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

23 mar 2009 kl. 14:42 skrev Chris Newman:

> I do think this is an important decision, so other opinions are  
> welcome.

So I've seen situations where people do MITM on purpose with protocols  
that looks like scram.

If I was an server owner I would be concerned about 3rd parties using  
my server to authenticate my users w/o me knowing using my server.

"to login, just use your foo password, and since we are using your  
SCRAM we wont be able to get your password", but impersonate the user  
to any service we want here the user uses the same password.

I don't think its realistic that a service deployer can not deploy  
scram w/o cb  since some clients are simply not going to work then.

Love




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NMT3Nm052314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 15: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 n2NMT3ul052313; Mon, 23 Mar 2009 15:29:03 -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 n2NMSqK8052298 for <[e-mail]>; Mon, 23 Mar 2009 15:29:03 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2NMSqwq020959 for <[e-mail]>; Mon, 23 Mar 2009 22:28:52 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2NMSqhN034494 for <[e-mail]>; Mon, 23 Mar 2009 16:28:52 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2NMJcoZ003132; Mon, 23 Mar 2009 17:19:38 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2NMJbRL003131; Mon, 23 Mar 2009 17:19:37 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Mar 2009 17:19:37 -0500
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: [e-mail]
Subject: Re: Inclusion of service name or URI in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 23, 2009 at 02:42:13PM -0700, Chris Newman wrote:
> I had a hallway conversation with Love where he asked about including a URI 
> or service name in the authentication hash as DIGEST does.

You and I have also had this conversation, twice I believe.

> I do not support adding service name or URI to SCRAM.  CRAM doesn't have it 
> and I think it's a confusing and complex feature in digest.  I'd prefer to 
> have one mechanism to do MITM defenses (channel bindings), I'd prefer that 
> mechanism be complete, and the market will decide if MITM defenses are 
> important enough to deploy that mechanism.  I don't want to make SCRAM more 
> complex to provide half-defenses in the event channel bindings don't deploy.
> 
> I do think this is an important decision, so other opinions are welcome.

I believe that making SCRAM deployment simple is, indeed, important.

I do believe that a mode of operation (under a different mechanism name,
mind you) where the salt includes the server name is, or, rather could
have been important.  And it should come with an infrastructure service
protocol for servers to use during the exchange (to avoid having to
store N StoredKeys for N servers in a user realm).

What is valuable about such a mode of operation is this: after a user
authenticates once to a server using SCRAM the server can then
impersonate the user to other servers using the same StoredKey, but if
the password is salted with the server name then the server can only
impersonate the user to itself.

Arguably environments that care about that problem ought to be using
Kerberos V and/or user certs (via PKINIT or in TLS).  Which is why I
don't think we need to require a servername-salted mode of SCRAM.

Perhaps someone has a use case where neither SCRAM as-is nor Kerberos V
would be appropriate but where a servername-salted-password variant of
SCRAM would be?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NLgdln049941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 14:42:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NLgd3Q049940; Mon, 23 Mar 2009 14:42:39 -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 n2NLgTtP049928 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 23 Mar 2009 14:42: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 n2NLgSix001664 for <[e-mail]>; Mon, 23 Mar 2009 14:42:28 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; format=flowed; charset=us-ascii
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <[e-mail]> for [e-mail]; Mon, 23 Mar 2009 14:42:28 -0700 (PDT)
Received: from [10.0.1.2] (dhcp-16f4.meeting.ietf.org [130.129.22.244]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 23 Mar 2009 14:42:28 -0700 (PDT)
Date: Mon, 23 Mar 2009 14:42:13 -0700
From: Chris Newman <[e-mail]>
Subject: Inclusion of service name or URI in SCRAM
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Sender: [e-mail]
Precedence: 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 had a hallway conversation with Love where he asked about including a URI 
or service name in the authentication hash as DIGEST does.

An example of the threat is that a user can authenticate to a "bad XMPP" 
server which proxies the salt and nonces to a "good LDAP" server.  As long 
as channel bindings are not used, the client will successfully authenticate 
mutually to the "bad XMPP" server and the bad server will have full access 
to the "good LDAP" server (indeed to all servers which use that same salt).

If the service name "xmpp" (or an xmpp uri) was included by the client in 
the hash, this authentication would fail without channel bindings.  So this 
provides "lightweight" protection against a subset of man-in-the-middle 
attacks, but does not protect against all such attacks the way channel 
bindings does.

I made a deliberate choice to omit service/uri from SCRAM, being aware of 
this attack vector.

I found the "URI" parameter in digest confusing and a deployment barrier. 
What does the hostname in the "URI" mean?  What sort of checks should be 
performed on it?  What if the URI doesn't include a hostname?  Can a user 
have multiple passwords on the same host and what are the client UI 
implications for that?

The service name is simpler, but I consider the functionality it provides 
both redundant with and inferior to channel bindings.

The counter-argument would be that including a string in the password hash 
(particularly a service name) is simpler to implement than channel 
bindings.  So if we want some man-in-the-middle defenses without channel 
bindings, we need that feature.

I do not support adding service name or URI to SCRAM.  CRAM doesn't have it 
and I think it's a confusing and complex feature in digest.  I'd prefer to 
have one mechanism to do MITM defenses (channel bindings), I'd prefer that 
mechanism be complete, and the market will decide if MITM defenses are 
important enough to deploy that mechanism.  I don't want to make SCRAM more 
complex to provide half-defenses in the event channel bindings don't deploy.

I do think this is an important decision, so other opinions are welcome.

		- 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 n2NKEU72044916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 13:14:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NKEURv044915; Mon, 23 Mar 2009 13:14: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-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 n2NKEJWk044901 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 23 Mar 2009 13:14: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 n2NKEI0v001644 for <[e-mail]>; Mon, 23 Mar 2009 13:14:19 -0700 (PDT)
MIME-version: 1.0
Content-disposition: inline
Content-type: text/plain; format=flowed; charset=utf-8
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <[e-mail]> for [e-mail]; Mon, 23 Mar 2009 13:14:18 -0700 (PDT)
Received: from [10.0.1.2] (dhcp-16f4.meeting.ietf.org [130.129.22.244]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <[e-mail]>; Mon, 23 Mar 2009 13:14:13 -0700 (PDT)
Date: Mon, 23 Mar 2009 13:13:56 -0700
From: Chris Newman <[e-mail]>
Subject: deriving client and server key
In-reply-to: <[e-mail]>
To: =?UTF-8?Q?Love_H=C3=B6rnquist_=C3=85strand?= <[e-mail]>, Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Message-id: <B5048FA51FC6B2F3E0585454@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-transfer-encoding: QUOTED-PRINTABLE
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On February 23, 2009 8:59:44 -0800 Love H=C3=B6rnquist =C3=85strand=
 <[e-mail]>=20
wrote:
> Right now the client and server key differences is:
>
> ClientKey =3D H(SaltedPassword)
> ServerKey =3D HMAC(SaltedPassword, salt)
>
> Why are the derived by two different methods ? (why not XKey =3D
> HMAC(SaltedKey, "X key")

I just realized I hadn't mentioned publicly that I think this would b=
e a=20
good change.

Specifically:

 ClientKey =3D HMAC(SaltedPassword, "Client Key")
 ServerKey =3D HMAC(SaltedPassword, "Server Key")

I think this actually makes the algorithm description a bit easier to=
=20
understand.  What do others think?

=09=09- 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 n2NGMsxw029337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 09:22:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NGMsP9029336; Mon, 23 Mar 2009 09:22:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NGMhJu029316 for <[e-mail]>; Mon, 23 Mar 2009 09:22:54 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2NGMh2i005125 for <[e-mail]>; Mon, 23 Mar 2009 16:22:43 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2NGMh0b047489 for <[e-mail]>; Mon, 23 Mar 2009 10:22:43 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2NGDUYS002797 for <[e-mail]>; Mon, 23 Mar 2009 11:13:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2NGDUq0002796 for [e-mail]; Mon, 23 Mar 2009 11:13:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 23 Mar 2009 11:13:30 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: New SCRAM and GS2 I-Ds
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
been posted.

These reflect the new GS2 design.

The changes from draft-newman-auth-scram-10 to -11 are fairly small.

To view the diffs side by side go here:

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-10.txt&url2=http://tools.ietf.org/id/draft-newman-auth-scram-11.txt

or

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-newman-auth-scram-10.txt&url2=http://www.ietf.org/internet-drafts/draft-newman-auth-scram-11.txt

(The former yields "[t]he files are identical" because tools.ietf.org
hasn't updated yet.)

Many of the changes result from switching I-D source from nroff to XML.
The IETF rfcdiff tool nicely renders these changes in the side-by-side
diff.  I've a traditional diff based on a copy of -10 edited to remove
most of these incidental differences -- I can post it if there's
interest.

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 n2NFjrju026586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 08:45:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2NFjr0v026585; Mon, 23 Mar 2009 08:45:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2NFjr6k026579 for <[e-mail]>; Mon, 23 Mar 2009 08:45:53 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id E40F63A6B22; Mon, 23 Mar 2009 08:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-gs2-11.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 23 Mar 2009 08:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


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

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

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

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2LI8ssX086048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Mar 2009 11:08:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2LI8s49086047; Sat, 21 Mar 2009 11:08:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2LI8i35086037 for <[e-mail]>; Sat, 21 Mar 2009 11:08:54 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2LI8hfC010827 for <[e-mail]>; Sat, 21 Mar 2009 18:08:43 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2LI8h2i037001 for <[e-mail]>; Sat, 21 Mar 2009 12:08:43 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2LHxWsi001527; Sat, 21 Mar 2009 12:59:32 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2LHxWSV001526; Sat, 21 Mar 2009 12:59:32 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 21 Mar 2009 12:59:31 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: New GS2: pulling everything together
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Mar 21, 2009 at 08:33:35AM -0700, Alexey Melnikov wrote:
> Nico,
> This is a good summary, thanks for doing it.
> 
> Nicolas Williams wrote:
> 
> >  Note that the two mechanism scheme does not imply any changes to the
> >  SASL APIs that weren't already implied by the pure SASL SCRAM.  The
> >  client and server SASL APIs require two additional application
> >  inputs: a) whether the application and TLS stack support channel
> >  binding, b) channel binding data from TLS.
> >
> One side question: are we reasonably sure that TLS CB is going to be the 
> only CB-type we will use in a foreseeable future?

In my summary I mentioned TLS specifically, but really, the APIs
shouldn't care what kind of channel it is -- they need the channel
binding type and data.

As to your question: given the SASL apps we have now, yes.  Eventually
we'll have IPsec channel binding too.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2LGmDsd082759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Mar 2009 09:48:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2LGmDsF082758; Sat, 21 Mar 2009 09:48: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 n2LGm19i082741 for <[e-mail]>; Sat, 21 Mar 2009 09:48:12 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 21 Mar 2009 16:48:00 +0000
Message-ID: <[e-mail]>
Date: Sat, 21 Mar 2009 08:33:35 -0700
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <[e-mail]>
CC: [e-mail]
Subject: Re: New GS2: pulling everything together
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nico,
This is a good summary, thanks for doing it.

Nicolas Williams wrote:

>   Note that the two mechanism scheme does not imply any changes to the
>   SASL APIs that weren't already implied by the pure SASL SCRAM.  The
>   client and server SASL APIs require two additional application
>   inputs: a) whether the application and TLS stack support channel
>   binding, b) channel binding data from TLS.
>
One side question: are we reasonably sure that TLS CB is going to be the 
only CB-type we will use in a foreseeable future?




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JGbd3H039337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 09:37:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2JGbdsj039336; Thu, 19 Mar 2009 09:37:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2JGbT7F039314 for <[e-mail]>; Thu, 19 Mar 2009 09:37:39 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2JGbSUq004613 for <[e-mail]>; Thu, 19 Mar 2009 16:37:28 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2JGbSMs000567 for <[e-mail]>; Thu, 19 Mar 2009 10:37:28 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2JGSItC029324 for <[e-mail]>; Thu, 19 Mar 2009 11:28:18 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2JGS5lt029323 for [e-mail]; Thu, 19 Mar 2009 11:28:05 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 19 Mar 2009 11:28:05 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Diffs to draft-newman-auth-scram-10 for new GS2
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here's my diffs.  See Appendix C for a list of changes.

[NOTE: These are slightly massaged because the conversion of
draft-newman-auth-scram-10 from nroff to XML source created some
gratouitous diffs, mostly the symbol used for bulletted lists, but also
indentation, reference naming and misc such diffs.  The edits I made to
get these diffs were to correct for indentation, bullet symbols,
wrapping and to put two spaces between sentence ending periods and the
next sentence; I also removed the page headers and footers and
associated whitespace.]



--- a	2009-03-19 10:35:18.666715000 -0500
+++ b	2009-03-19 11:20:16.791477000 -0500
@@ -1,828 +1,1072 @@
-Network Working Group                                  Abhijit Menon-Sen
-Internet-Draft                                    Oryx Mail Systems GmbH
-Intended Status: Proposed Standard                          Chris Newman
-Expires: August 2009                                    Sun Microsystems
-                                                         Alexey Melnikov
-                                                               Isode Ltd
-                                                       February 21, 2009
 
 
-            Salted Challenge Response (SCRAM) SASL Mechanism
 
-                     draft-newman-auth-scram-10.txt
+NETWORK WORKING GROUP                                       A. Menon-Sen
+Internet-Draft                                    Oryx Mail Systems GmbH
+Intended status: Standards Track                             A. Melnikov
+Expires: September 20, 2009                                    Isode Ltd
+                                                               C. Newman
+                                                             N. Williams
+                                                        Sun Microsystems
+                                                          March 19, 2009
+
 
+            Salted Challenge Response (SCRAM) SASL Mechanism
+                     draft-newman-auth-scram-11.txt
 
 Status of this Memo
 
    This Internet-Draft is submitted to IETF in full conformance with the
    provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.  The list of Internet-
-   Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
+   http://www.ietf.org/ietf/1id-abstracts.txt.
 
-   This Internet-Draft expires in July 2009.
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
 
+   This Internet-Draft will expire on September 20, 2009.
 
 Copyright Notice
 
    Copyright (c) 2009 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.
 
 Abstract
 
    The secure authentication mechanism most widely deployed and used by
    Internet application protocols is the transmission of clear-text
    passwords over a channel protected by Transport Layer Security (TLS).
    There are some significant security concerns with that mechanism,
    which could be addressed by the use of a challenge response
    authentication mechanism protected by TLS.  Unfortunately, the
    challenge response mechanisms presently on the standards track all
    fail to meet requirements necessary for widespread deployment, and
    have had success only in limited use.
 
    This specification describes a family of authentication mechanisms
    called the Salted Challenge Response Authentication Mechanism
    (SCRAM), which addresses the security concerns and meets the
    deployability requirements.  When used in combination with TLS or an
    equivalent security layer, a mechanism from this family could improve
    the status-quo for application protocol authentication and provide a
    suitable choice for a mandatory-to-implement mechanism for future
    application protocol standards.
 
+Table of Contents
+
+   1.          Conventions Used in This Document  . . . . . . . . . .  4
+   1.1.        Terminology  . . . . . . . . . . . . . . . . . . . . .  4
+   1.2.        Notation . . . . . . . . . . . . . . . . . . . . . . .  5
+   2.          Introduction . . . . . . . . . . . . . . . . . . . . .  7
+   3.          SCRAM Algorithm Overview . . . . . . . . . . . . . . .  9
+   4.          SCRAM Mechanism Names  . . . . . . . . . . . . . . . . 10
+   5.          SCRAM Authentication Exchange  . . . . . . . . . . . . 11
+   5.1.        SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
+   6.          Channel Binding  . . . . . . . . . . . . . . . . . . . 15
+   6.1.        Channel Binding to TLS Channels  . . . . . . . . . . . 16
+   7.          Formal Syntax  . . . . . . . . . . . . . . . . . . . . 17
+   8.          SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20
+   8.1.        GSS-API Principal Name Types for SCRAM . . . . . . . . 20
+   8.2.        GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20
+   8.3.        GSS_Pseudo_random() for SCRAM  . . . . . . . . . . . . 21
+   9.          Security Considerations  . . . . . . . . . . . . . . . 22
+   10.         IANA Considerations  . . . . . . . . . . . . . . . . . 23
+   11.         Acknowledgements . . . . . . . . . . . . . . . . . . . 24
+   Appendix A. Other Authentication Mechanisms  . . . . . . . . . . . 25
+   Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 26
+   Appendix C. SCRAM Examples and Internet-Draft Change History . . . 27
+   12.         References . . . . . . . . . . . . . . . . . . . . . . 30
+   12.1.       Normative References . . . . . . . . . . . . . . . . . 30
+   12.2.       Normative References for GSS-API implementors  . . . . 30
+   12.3.       Informative References . . . . . . . . . . . . . . . . 31
+               Authors' Addresses . . . . . . . . . . . . . . . . . . 33
 
 1.  Conventions Used in This Document
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].
 
    Formal syntax is defined by [RFC5234] including the core rules
    defined in Appendix B of [RFC5234].
 
    Example lines prefaced by "C:" are sent by the client and ones
    prefaced by "S:" by the server.  If a single "C:" or "S:" label
    applies to multiple lines, then the line breaks between those lines
    are for editorial clarity only, and are not part of the actual
    protocol exchange.
 
-
 1.1.  Terminology
 
    This document uses several terms defined in [RFC4949] ("Internet
    Security Glossary") including the following: authentication,
    authentication exchange, authentication information, brute force,
    challenge-response, cryptographic hash function, dictionary attack,
    eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
    one-way encryption function, password, replay attack and salt.
    Readers not familiar with these terms should use that glossary as a
    reference.
 
    Some clarifications and additional definitions follow:
 
    o Authentication information: Information used to verify an identity
      claimed by a SCRAM client.  The authentication information for a
      SCRAM identity consists of salt, iteration count, the "StoredKey"
      and "ServerKey" (as defined in the algorithm overview) for each
      supported cryptographic hash function.
 
    o Authentication database: The database used to look up the
      authentication information associated with a particular identity.
      For application protocols, LDAPv3 (see [RFC4510]) is frequently
      used as the authentication database.  For network-level protocols
      such as PPP or 802.11x, the use of RADIUS is more common.
 
    o Base64: An encoding mechanism defined in [RFC4648] which converts
      an octet string input to a textual output string which can be
      easily displayed to a human.  The use of base64 in SCRAM is
      restricted to the canonical form with no whitespace.
 
    o Octet: An 8-bit byte.
 
    o Octet string: A sequence of 8-bit bytes.
 
-   o Salt: A random octet string that is combined with a password before
-     applying a one-way encryption function.  This value is used to
-     protect passwords that are stored in an authentication database.
-
+   o  Salt: A random octet string that is combined with a password
+      before applying a one-way encryption function.  This value is used
+      to protect passwords that are stored in an authentication
+      database.
 
 1.2.  Notation
 
    The pseudocode description of the algorithm uses the following
    notations:
 
    o ":=": The variable on the left hand side represents the octet
      string resulting from the expression on the right hand side.
 
    o "+": Octet string concatenation.
 
    o "[ ]": A portion of an expression enclosed in "[" and "]" may not
      be included in the result under some circumstances.  See the
      associated text for a description of those circumstances.
 
    o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
      [RFC2104]) using the octet string represented by "key" as the key
      and the octet string "str" as the input string.  The size of the
      result is the hash result size for the hash function in use.  For
      example, it is 20 octets for SHA-1 (see [RFC3174]).
 
    o H(str): Apply the cryptographic hash function to the octet string
      "str", producing an octet string as a result.  The size of the
      result depends on the hash result size for the hash function in
      use.
 
    o XOR: Apply the exclusive-or operation to combine the octet string
      on the left of this operator with the octet string on the right of
-     this operator.  The length of the output and each of the two inputs
-     will be the same for this use.
+      this operator.  The length of the output and each of the two
+      inputs will be the same for this use.
 
    o Hi(str, salt):
 
+
+
          U0   := HMAC(str, salt + INT(1))
          U1   := HMAC(str, U0)
          U2   := HMAC(str, U1)
          ...
          Ui-1 := HMAC(str, Ui-2)
          Ui   := HMAC(str, Ui-1)
 
          Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
+
      where "i" is the iteration count, "+" is the string concatenation
-     operator and INT(g) is a four-octet encoding of the integer g, most
-     significant octet first.
+      operator and INT(g) is a four-octet encoding of the integer g,
+      most significant octet first.
 
-     This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
+   o  This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
      with dkLen == output length of HMAC() == output length of H().
 
-
 2.  Introduction
 
    This specification describes a family of authentication mechanisms
    called the Salted Challenge Response Authentication Mechanism (SCRAM)
    which addresses the requirements necessary to deploy a challenge-
    response mechanism more widely than past attempts.  When used in
-   combination with Transport Layer Security (TLS, see [TLS]) or an
+   combination with Transport Layer Security (TLS, see [RFC5246]) or an
    equivalent security layer, a mechanism from this family could improve
    the status-quo for application protocol authentication and provide a
    suitable choice for a mandatory-to-implement mechanism for future
    application protocol standards.
 
    For simplicity, this family of mechanism does not presently include
    negotiation of a security layer.  It is intended to be used with an
-   external security layer such as that provided by TLS or SSH.
+   external security layer such as that provided by TLS or SSH, with
+   optional channel binding [RFC5056] to the external security layer.
+
+   SCRAM is specified herein as a pure Simple Authentication and
+   Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
+   bridge between SASL and the Generic Security Services Application
+   Programming Interface (GSS-API) called "GS2" [ref-needed].  This
+   means that SCRAM is actually both, a GSS-API and SASL mechanism.
 
    SCRAM provides the following protocol features:
 
    o The authentication information stored in the authentication
      database is not sufficient by itself to impersonate the client.
-     The information is salted to prevent a pre-stored dictionary attack
-     if the database is stolen.
+      The information is salted to prevent a pre-stored dictionary
+      attack if the database is stolen.
 
    o The server does not gain the ability to impersonate the client to
      other servers (with an exception for server-authorized proxies).
 
    o The mechanism permits the use of a server-authorized proxy without
      requiring that proxy to have super-user rights with the back-end
      server.
 
    o A standard attribute is defined to enable storage of the
      authentication information in LDAPv3 (see [RFC4510]).
 
-   o Both the client and server can be authenticated by the protocol.
+   o  Mutual authentication is supported, but only the client is named
+      (i.e., the server has no name).
 
    For an in-depth discussion of why other challenge response mechanisms
    are not considered sufficient, see appendix A.  For more information
    about the motivations behind the design of this mechanism, see
    appendix B.
 
-   Comments regarding this draft may be sent either to the ietf-
-   [e-mail] mailing list or to the authors.
-
+   Comments regarding this draft may be sent either to the
+   [e-mail] mailing list or to the authors.
 
 3.  SCRAM Algorithm Overview
 
    Note that this section omits some details, such as client and server
    nonces.  See Section 5 for more details.
 
    To begin with, the client is in possession of a username and
    password.  It sends the username to the server, which retrieves the
    corresponding authentication information, i.e.  a salt, StoredKey,
    ServerKey and the iteration count i.  (Note that a server
    implementation may chose to use the same iteration count for all
    account.) The server sends the salt and the iteration count to the
    client, which then computes the following values and sends a
    ClientProof to the server:
 
+
         SaltedPassword  := Hi(password, salt)
         ClientKey       := H(SaltedPassword)
         StoredKey       := H(ClientKey)
         AuthMessage     := client-first-message + "," +
                            server-first-message + "," +
                            client-final-message-without-proof
         ClientSignature := HMAC(StoredKey, AuthMessage)
         ClientProof     := ClientKey XOR ClientSignature
         ServerKey       := HMAC(SaltedPassword, salt)
         ServerSignature := HMAC(ServerKey, AuthMessage)
 
+
    The server authenticates the client by computing the ClientSignature,
    exclusive-ORing that with the ClientProof to recover the ClientKey
    and verifying the correctness of the ClientKey by applying the hash
    function and comparing the result to the StoredKey.  If the ClientKey
    is correct, this proves that the client has access to the user's
    password.
 
    Similarly, the client authenticates the server by computing the
    ServerSignature and comparing it to the value sent by the server.  If
    the two are equal, it proves that the server had access to the user's
    ServerKey.
 
    The AuthMessage is computed by concatenating messages from the
    authentication exchange.  The format of these messages is defined in
-   the Formal Syntax section.
+   Section 7.
 
-
-4.  SCRAM mechanism names
+4.  SCRAM Mechanism Names
 
    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
    uppercased name of the underlying hashed function taken from the IANA
-   "Hash Function Textual Names" registry (see http://www.iana.org).
+   "Hash Function Textual Names" registry (see http://www.iana.org),
+   optionally followed by the suffix "-PLUS" (see below)..
 
    For interoperability, all SCRAM clients and servers MUST implement
-   the SCRAM-HMAC-SHA-1 authentication mechanism, i.e.  an
-   authentication mechanism from the SCRAM family that uses the SHA-1
-   hash function as defined in [RFC3174].
-
+   the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an authentication
+   mechanism from the SCRAM family that uses the SHA-1 hash function as
+   defined in [RFC3174].
+
+   The "-PLUS" suffix is used only when the server supports channel
+   binding to the external channel.  In this case the server will
+   advertise both, SCRAM-HMAC-SHA-1 and SCRAM-HMAC-SHA-1-PLUS, otherwise
+   the server will advertise only SCRAM-HMAC-SHA-1.  The "-PLUS" exists
+   to allow negotiation of the use of channel binding.  See Section 6.
 
 5.  SCRAM Authentication Exchange
 
    SCRAM is a text protocol where the client and server exchange
    messages containing one or more attribute-value pairs separated by
    commas.  Each attribute has a one-letter name.  The messages and
-   their attributes are described in section 5.1, and defined in the
-   Formal Syntax section.
+   their attributes are described in Section 5.1, and defined in
+   Section 7.
 
    This is a simple example of a SCRAM-HMAC-SHA-1 authentication
    exchange:
-        C: n=Chris Newman,r=ClientNonce
+
+
+      C: n,n=Chris Newman,r=ClientNonce
         S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
         S: v=WxPv/siO5l+qxN4
 
-   With channel-binding data sent by the client this might look like this:
 
-        C: n=Chris Newman,r=ClientNonce
+   With channel-binding data sent by the client this might look like
+   this:
+
+
+      C: p,n=Chris Newman,r=ClientNonce
         S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
         C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
         S: v=WxPv/siO5l+qxN4
 
+
    <<Note that the channel-bind data above, as well as all hashes are
    fake>>
 
-   First, the client sends a message containing the username, and a
-   random, unique nonce.  In response, the server sends the user's
-   iteration count i, the user's salt, and appends its own nonce to the
-   client-specified one.  The client then responds with the same nonce
-   and a ClientProof computed using the selected hash function as
-   explained earlier.  In this step the client can also include an
-   optional authorization identity.  The server verifies the nonce and
-   the proof, verifies that the authorization identity (if supplied by
-   the client in the second message) is authorized to act as the
-   authentication identity, and, finally, it responds with a
-   ServerSignature, concluding the authentication exchange.  The client
-   then authenticates the server by computing the ServerSignature and
-   comparing it to the value sent by the server.  If the two are
-   different, the client MUST consider the authentication exchange to be
-   unsuccessful and it might have to drop the connection.
+   First, the client sends a message containing:
 
+   o  a GS2 header consisting of a flag indicating whether channel
+      binding is supported-but-not-used, not supported, or used, and the
+      SASL authzid (optional);
+
+   o  SCRAM username and client nonce attributes.
+
+   In response, the server sends the user's iteration count i, the
+   user's salt, and appends its own nonce to the client-specified one.
+   The client then responds with the same nonce and a ClientProof
+   computed using the selected hash function as explained earlier.  In
+   this step the client can also include an optional authorization
+   identity.  The server verifies the nonce and the proof, verifies that
+   the authorization identity (if supplied by the client in the second
+   message) is authorized to act as the authentication identity, and,
+   finally, it responds with a ServerSignature, concluding the
+   authentication exchange.  The client then authenticates the server by
+   computing the ServerSignature and comparing it to the value sent by
+   the server.  If the two are different, the client MUST consider the
+   authentication exchange to be unsuccessful and it might have to drop
+   the connection.
 
-5.1 SCRAM attributes
+5.1.  SCRAM Attributes
 
    This section describes the permissible attributes, their use, and the
    format of their values.  All attribute names are single US-ASCII
    letters and are case-sensitive.
 
-   o a: This optional attribute specifies an authorization identity.  A
-   client may include it in its second message to the server if it wants
-   to authenticate as one user, but subsequently act as a different
-   user.  This is typically used by an administrator to perform some
-   management task on behalf of another user, or by a proxy in some
-   situations.
-
-     Upon the receipt of this value the server verifies its correctness
-     according to the used SASL protocol profile.  Failed verification
-     results in failed authentication exchange.
+   o  a: This is an optional attribute, and is part of the GS2 [ref-
+      needed] bridge between the GSS-API and SASL.  This attribute
+      specifies an authorization identity.  A client may include it in
+      its second message to the server if it wants to authenticate as
+      one user, but subsequently act as a different user.  This is
+      typically used by an administrator to perform some management task
+      on behalf of another user, or by a proxy in some situations.
+
+         Upon the receipt of this value the server verifies its
+         correctness according to the used SASL protocol profile.
+         Failed verification results in failed authentication exchange.
 
      If this attribute is omitted (as it normally would be), or
      specified with an empty value, the authorization identity is
      assumed to be derived from the username specified with the
      (required) "n" attribute.
 
      The server always authenticates the user specified by the "n"
-     attribute.  If the "a" attribute specifies a different user, the
-     server associates that identity with the connection after
+         attribute.  If the "a" attribute specifies a different user,
+         the server associates that identity with the connection after
      successful authentication and authorization checks.
 
-     The syntax of this field is the same as that of the "n" field with
-     respect to quoting of '=' and ','.
+         The syntax of this field is the same as that of the "n" field
+         with respect to quoting of '=' and ','.
 
    o n: This attribute specifies the name of the user whose password is
      used for authentication.  A client must include it in its first
      message to the server.  If the "a" attribute is not specified
      (which would normally be the case), this username is also the
-     identity which will be associated with the connection subsequent to
-     authentication and authorization.
+      identity which will be associated with the connection subsequent
+      to authentication and authorization.
 
-     Before sending the username to the server, the client MUST prepare
-     the username using the "SASLPrep" profile [SASLPrep] of the
-     "stringprep" algorithm [RFC3454]. If the preparation of the
-     username fails or results in an empty string, the client SHOULD
-     abort the authentication exchange (*).
+         Before sending the username to the server, the client MUST
+         prepare the username using the "SASLPrep" profile [RFC4013] of
+         the "stringprep" algorithm [RFC3454].  If the preparation of
+         the username fails or results in an empty string, the client
+         SHOULD abort the authentication exchange (*).
 
      (*) An interactive client can request a repeated entry of the
      username value.
 
      Upon receipt of the username by the server, the server SHOULD
-     prepare it using the "SASLPrep" profile [SASLPrep] of the
+         prepare it using the "SASLPrep" profile [RFC4013] of the
      "stringprep" algorithm [RFC3454]. If the preparation of the
      username fails or results in an empty string, the server SHOULD
      abort the authentication exchange.
 
-     The characters ',' or '=' in usernames are sent as '=2C' and '=3D'
-     respectively.  If the server receives a username which contains '='
-     not followed by either '2C' or '3D', then the server MUST fail the
-     authentication.
+         The characters ',' or '=' in usernames are sent as '=2C' and
+         '=3D' respectively.  If the server receives a username which
+         contains '=' not followed by either '2C' or '3D', then the
+         server MUST fail the authentication.
 
    o m: This attribute is reserved for future extensibility.  In this
-     version of SCRAM, its presence in a client or a server message MUST
-     cause authentication failure when the attribute is parsed by the
-     other end.
+      version of SCRAM, its presence in a client or a server message
+      MUST cause authentication failure when the attribute is parsed by
+      the other end.
 
    o r: This attribute specifies a sequence of random printable
-     characters excluding ',' which forms the nonce used as input to the
-     hash function.  No quoting is applied to this string (<<unless the
-     binding of SCRAM to a particular protocol states otherwise>>).  As
-     described earlier, the client supplies an initial value in its
+      characters excluding ',' which forms the nonce used as input to
+      the hash function.  No quoting is applied to this string (<<unless
+      the binding of SCRAM to a particular protocol states otherwise>>).
+      As described earlier, the client supplies an initial value in its
      first message, and the server augments that value with its own
      nonce in its first response.  It is important that this be value
-     different for each authentication.  The client MUST verify that the
-     initial part of the nonce used in subsequent messages is the same
-     as the nonce it initially specified.  The server MUST verify that
-     the nonce sent by the client in the second message is the same as
-     the one sent by the server in its first message.
-
-   o c: This optional attribute specifies base64-encoded channel-
-     binding data.  It is sent by the client in the second step.  If
-     specified by the client, if the server supports the specified
-     channel binding type and if the server can't verify it, then the
-     server MUST fail the authentication exchange.  Whether this
-     attribute is included, and the meaning and contents of the
-     channel-binding data depends on the external security layer in use.
-     This is necessary to detect a man-in-the-middle attack on the
-     security layer.
+      different for each authentication.  The client MUST verify that
+      the initial part of the nonce used in subsequent messages is the
+      same as the nonce it initially specified.  The server MUST verify
+      that the nonce sent by the client in the second message is the
+      same as the one sent by the server in its first message.
+
+   o  c: This REQUIRED attribute specifies base64-encoded of a header
+      and the channel-binding data.  It is sent by the client in its
+      second authentication message.  The header consist of:
+
+      *  the GS2 header from the client's first message (recall: a
+         channel binding flag and an optional authzid);
+
+      *  followed by the external channel's channel binding type prefix
+         (see [RFC5056], if and only if the client is using channel
+         binding;
+
+      *  followed by the external channel's channel binding data, if and
+         only if the client is using channel binding.
 
    o s: This attribute specifies the base64-encoded salt used by the
      server for this user.  It is sent by the server in its first
      message to the client.
 
    o i: This attribute specifies an iteration count for the selected
      hash function and user, and must be sent by the server along with
      the user's salt.
 
-     For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash
-     iteration-count of at least 128.
+         For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a
+         hash iteration-count of at least 128.
 
    o p: This attribute specifies a base64-encoded ClientProof.  The
-   client computes this value as described in the overview and sends it
-   to the server.
+      client computes this value as described in the overview and sends
+      it to the server.
 
    o v: This attribute specifies a base64-encoded ServerSignature.  It
    is sent by the server in its final message, and may be used by the
    client to verify that the server has access to the user's
-   authentication information.  This value is computed as explained in
-   the overview.
+      authentication information.  This value is computed as explained
+      in the overview.
+
+6.  Channel Binding
 
+   SCRAM supports channel binding to external secure channels, such as
+   TLS.  Clients and servers may or may not support channel binding,
+   therefore the use of channel binding is negotiable.  SCRAM does not
+   provide security layers, however, therefore it is imperative that
+   SCRAM provide integrity protection for the negotiation of channel
+   binding.
+
+   Use of channel binding is negotiated as follows:
+
+   o  The server advertises support for channel binding by advertising
+      both, SCRAM-HMAC-<hash-function> and SCRAM-HMAC-<hash-function>-
+      PLUS.
+
+   o  If the client negotiates mechanisms then client MUST select SCRAM-
+      HMAC-<hash-function>-PLUS if offered by the server.  Otherwise, if
+      the client does not negotiate mechanisms then it MUST select only
+      SCRAM-HMAC-<hash-function> (not suffixed with "-PLUS").
+
+   o  If the client and server both support channel binding, or if the
+      client wishes to use channel binding but the client does not
+      negotiate mechanisms, the client MUST set the GS2 channel binding
+      flag to "p" and MUST include channel binding data for the external
+      channel in the computation of the "c=" attribute (see
+      Section 5.1).
+
+   o  If the client supports channel binding but the server does not
+      then the client MUST set the GS2 channel binding flag to "y" and
+      MUST NOT include channel binding data for the external channel in
+      the computation of the "c=" attribute (see Section 5.1).
+
+   o  If the client does not support channel binding then the client
+      MUST set the GS2 channel binding flag to "n" and MUST NOT include
+      channel binding data for the external channel in the computation
+      of the "c=" attribute (see Section 5.1).
+
+   o  If the server receives a client first message with the GS2 channel
+      binding flag set to "y" and the server supports channel binding
+      the server MUST fail authentication.  This is because if the
+      client sets the GS2 channel binding flag set to "y" then the
+      client must have believed that the server did not support channel
+      binding -- if the server did in fact support channel binding then
+      this is an indication that there has been a downgrade attack
+      (e.g., an attacker changed the server's mechanism list to exclude
+      the -PLUS suffixed SCRAM mechanism name(s)).
+
+   The server MUST always validate the client's "c=" field.  The server
+   does this by constructing the value of the "c=" attribute and then
+   checking that it matches the client's c= attribute value.
+
+6.1.  Channel Binding to TLS Channels
+
+   If an external TLS channel is to be bound into the SCRAM
+   authentication, and if the channel was established using a server
+   certificate to authenticate the server, then the SCRAM client and
+   server MUST use the 'tls-server-end-point' channel binding type.  See
+   the IANA Channel Binding Types registry.
+
+   If an external TLS channel is to be bound into the SCRAM
+   authentication, and if the channel was established without the use of
+   any server certificate to authenticate the server, then the SCRAM
+   client and server MUST use the 'tls-unique' channel binding type.
 
-6.  Formal Syntax
+7.  Formal Syntax
 
    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"
-   and "UTF8-4" non-terminal are defined in [UTF-8].
+   and "UTF8-4" non-terminal are defined in [RFC3629].
+
 
       generic-message = attr-val *("," attr-val)
                         ;; Generic syntax of any server challenge
                         ;; or client response
 
       attr-val        = ALPHA "=" value
 
-      value           = 1*(value-char)
+     value           = *(value-char)
 
       value-safe-char = %01-2B / %2D-3C / %3E-7F /
                         UTF8-2 / UTF-3 / UTF8-4
                         ;; UTF8-char except NUL, "=", and ",".
 
       value-char      = value-safe-char / "="
 
       base64-char     = ALPHA / DIGIT / "/" / "+"
 
       base64-4        = 4*4(base64-char)
 
       base64-3        = 3*3(base64-char) "="
 
       base64-2        = 2*2(base64-char) "=="
 
       base64          = *(base64-4) [base64-3 / base64-2]
 
       posit-number = (%x31-39) *DIGIT
                         ;; A positive number
 
       saslname        = 1*(value-safe-char / "=2C" / "=3D")
                         ;; Conforms to <value>
 
       authzid         = "a=" saslname
                         ;; Protocol specific.
 
+     gs2-cbind-flag  = "n" / "y" / "p"
+                       ;; "n" -> client doesn't support channel binding
+                       ;; "y" -> client does support channel binding
+                       ;;        but thinks the server does not.
+                       ;; "p" -> client requires channel binding
+     gs2-header      = gs2-cbind-flag [ authzid ] ","
+                       ;; GS2 header for SCRAM
+                       ;; (the actual GS2 header includes an optional
+                       ;; flag to indicate that the GSS mechanism is not
+                       ;; "standard" but since SCRAM is "standard" we
+                       ;; don't include that flag).
+
       username        = "n=" saslname
                         ;; Usernames are prepared using SASLPrep.
 
       reserved-mext  = "m=" 1*(value-char)
                         ;; Reserved for signalling mandatory extensions.
                         ;; The exact syntax will be defined in
                         ;; the future.
 
+     ;;cbind-type    = value
+     ;;cbind-input   = gs2-header [ value ":" cbind-data ]
       channel-binding = "c=" base64
+                       ;; base64 encoding of cbind-input
 
       proof           = "p=" base64
 
       nonce           = "r=" c-nonce [s-nonce]
                         ;; Second part provided by server.
 
       c-nonce         = value
 
       s-nonce         = value
 
       salt            = "s=" base64
 
       verifier        = "v=" base64
                         ;; base-64 encoded ServerSignature.
 
       iteration-count = "i=" posit-number
                         ;; A positive number
 
       client-first-message =
-                        [reserved-mext ","] username "," nonce [","
-                        extensions]
+                       gs2-header [reserved-mext ","]
+                       username "," nonce ["," extensions]
 
       server-first-message =
                         [reserved-mext ","] nonce "," salt ","
                         iteration-count ["," extensions]
 
       client-final-message-without-proof =
-                        [authzid ","] [channel-binding ","] nonce [","
+                       [channel-binding ","] nonce [","
                         extensions]
 
       client-final-message =
                         client-final-message-without-proof "," proof
 
       server-final-message =
                         verifier ["," extensions]
 
       extensions = attr-val *("," attr-val)
                         ;; All extensions are optional,
-			;; i.e.  unrecognized attributes ;; not defined
-			in this document ;; MUST be ignored.
+                       ;; i.e. unrecognized attributes
+                       ;; not defined in this document
+                       ;; MUST be ignored.
+
+8.  SCRAM as a GSS-API Mechanism
+
+   This section and its sub-sections and all normative references of it
+   not referenced elsewhere in this document are INFORMATIONAL for SASL
+   implementors, but they are NORMATIVE for GSS-API implementors.
+
+   SCRAM is actually also GSS-API mechanism.  The messages are the same,
+   but a) the GS2 header on the client's first message and channel
+   binding data is excluded when SCRAM is used as a GSS-API mechanism,
+   and b) the RFC2743 section 3.1 initial context token header is
+   prefixed to the client's first authentication message (context
+   token).
+
+   The GSS-API mechanism OID for SCRAM is <TBD> (see Section 10).
+
+8.1.  GSS-API Principal Name Types for SCRAM
+
+   SCRAM does not name acceptors.  Therefore only GSS_C_NO_NAME and
+   names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name
+   input of GSS_Init_sec_context() when using a SCRAM mechanism.
+
+   SCRAM supports only a single name type for initiators:
+   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
+   SCRAM.
+
+   There is no name canonicalization procedure for SCRAM beyond applying
+   SASLprep as described in Section 5.1.
+
+   The query, display and exported name syntax for SCRAM principal names
+   is the same: there is no syntax -- SCRAM principal names are free-
+   form.  (The exported name token does, of course, conform to [RFC2743]
+   section 3.2, but the "NAME" part of the token is just a SCRAM user
+   name.)
+
+8.2.  GSS-API Per-Message Tokens for SCRAM
+
+   The per-message tokens for SCRAM as a GSS-API mechanism SHALL BE the
+   same as those for the Kerberos V GSS-API mechanism [RFC4121], using
+   the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
 
+   The 128-bit session key SHALL be derived by using the least
+   significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
+   key" || ClientKey || AuthMessage).
 
-7.  Security Considerations
+   SCRAM does support PROT_READY, and is PROT_READY on the initiator
+   side first upon receipt of the server's reply to the initial security
+   context token.
+
+8.3.  GSS_Pseudo_random() for SCRAM
+
+   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
+   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
+   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
+   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
+
+9.  Security Considerations
 
    If the authentication exchange is performed without a strong security
    layer, then a passive eavesdropper can gain sufficient information to
    mount an offline dictionary or brute-force attack which can be used
    to recover the user's password.  The amount of time necessary for
    this attack depends on the cryptographic hash function selected, the
    strength of the password and the iteration count supplied by the
    server.  An external security layer with strong encryption will
    prevent this attack.
 
    If the external security layer used to protect the SCRAM exchange
    uses an anonymous key exchange, then the SCRAM channel binding
    mechanism can be used to detect a man-in-the-middle attack on the
    security layer and cause the authentication to fail as a result.
    However, the man-in-the-middle attacker will have gained sufficient
    information to mount an offline dictionary or brute-force attack.
    For this reason, SCRAM includes the ability to increase the iteration
    count over time.
 
    If the authentication information is stolen from the authentication
    database, then an offline dictionary or brute-force attack can be
    used to recover the user's password.  The use of salt mitigates this
    attack somewhat by requiring a separate attack on each password.
    Authentication mechanisms which protect against this attack are
    available (e.g., the EKE class of mechanisms), but the patent
    situation is presently unclear.
 
    If an attacker obtains the authentication information from the
    authentication repository and either eavesdrops on one authentication
    exchange or impersonates a server, the attacker gains the ability to
    impersonate that user to all servers providing SCRAM access using the
    same hash function, password, iteration count and salt.  For this
    reason, it is important to use randomly-generated salt values.
 
    If the server detects (from the value of the client-specified "h"
    attribute) that both endpoints support a stronger hash function that
    the one the client actually chooses to use, then it SHOULD treat this
    as a downgrade attack and reject the authentication attempt.
 
    A hostile server can perform a computational denial-of-service attack
    on clients by sending a big iteration count value.
 
-8.  IANA considerations
+10.  IANA Considerations
 
-   IANA is requested to add the following entry to the SASL Mechanism
+   IANA is requested to add the following entries to the SASL Mechanism
    registry established by [RFC4422]:
 
+
    To: [e-mail]
    Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1
 
    SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1
    Security considerations: Section 7 of [RFCXXXX]
    Published specification (optional, recommended): [RFCXXXX]
    Person & email address to contact for further information:
     IETF SASL WG <[e-mail]>
    Intended usage: COMMON
    Owner/Change controller: IESG <[e-mail]>
    Note:
 
+   To: [e-mail]
+   Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1-PLUS
+
+   SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1-PLUS
+   Security considerations: Section 7 of [RFCXXXX]
+   Published specification (optional, recommended): [RFCXXXX]
+   Person & email address to contact for further information:
+    IETF SASL WG <[e-mail]>
+   Intended usage: COMMON
+   Owner/Change controller: IESG <[e-mail]>
+   Note:
+
+
    Note that even though this document defines a family of SCRAM-HMAC
    mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in
    the SASL Mechanisms registry.  IANA is requested to prevent future
    registrations of SASL mechanisms starting with SCRAM-HMAC- without
    consulting the SASL mailing list <[e-mail]> first.
 
    Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC
    SASL mechanism MUST be explicitly registered with IANA and MUST
-   comply with SCRAM-HMAC mechanism naming convention defined in Section
-   4 of this document.
-
+   comply with SCRAM-HMAC mechanism naming convention defined in
+   Section 4 of this document.
 
+   We hereby request that IANA assign a GSS-API mechanism OID for SCRAM.
 
-9.  Acknowedgements
+11.  Acknowledgements
 
    The authors would like to thank Dave Cridland for his contributions
    to this document.
 
+Appendix A.  Other Authentication Mechanisms
 
-10.  Normative References
-
-    [RFC4648]  Josefsson, "The Base16, Base32, and Base64 Data
-               Encodings", RFC 4648, SJD, October 2006.
+   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
+   proved to be too complex to implement and test, and thus has poor
+   interoperability.  The security layer is often not implemented, and
+   almost never used; everyone uses TLS instead.  For a more complete
+   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
+   see [I-D.ietf-sasl-digest-to-historic].
 
-    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
-               10646", STD 63, RFC 3629, November 2003.
-
-    [RFC2104]  Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
-               Message Authentication", IBM, February 1997.
-
-    [RFC2119]  Bradner, "Key words for use in RFCs to Indicate
-               Requirement Levels", RFC 2119, Harvard University, March
-               1997.
-
-    [RFC3174]  Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC
-               3174, Motorola, September 2001
+   The CRAM-MD5 SASL mechanism, while widely deployed has also some
+   problems, in particular it is missing some modern SASL features such
+   as support for internationalized usernames and passwords, support for
+   passing of authorization identity, support for channel bindings.  It
+   also doesn't support server authentication.  For a more complete list
+   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
 
-    [RFC5234]  Crocker, Overell, "Augmented BNF for Syntax
-               Specifications: ABNF", RFC 5234, January 2008.
+   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+   eavesdropper to impersonate the authenticating user to any other
+   server for which the user has the same password.  It also sends the
+   password in the clear over the network, unless TLS is used.  Server
+   authentication is not supported.
 
-    [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security
-               Layer (SASL)", RFC 4422, Isode Limited, June 2006.
+Appendix B.  Design Motivations
 
-    [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user
-               names and passwords", RFC 4013, February 2005.
+   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
+   proved to be too complex to implement and test, and thus has poor
+   interoperability.  The security layer is often not implemented, and
+   almost never used; everyone uses TLS instead.  For a more complete
+   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
+   see [I-D.ietf-sasl-digest-to-historic].
 
-    [RFC3454] Hoffman, P., Blanchet, M., "Preparation of
-               Internationalized Strings ("stringprep")", RFC 3454,
-               December 2002.
+   The CRAM-MD5 SASL mechanism, while widely deployed has also some
+   problems, in particular it is missing some modern SASL features such
+   as support for internationalized usernames and passwords, support for
+   passing of authorization identity, support for channel bindings.  It
+   also doesn't support server authentication.  For a more complete list
+   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
 
+   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+   eavesdropper to impersonate the authenticating user to any other
+   server for which the user has the same password.  It also sends the
+   password in the clear over the network, unless TLS is used.  Server
+   authentication is not supported.
 
+Appendix C.  SCRAM Examples and Internet-Draft Change History
 
-11.  Informative References
+   <<To be written.>>
 
-    [RFC2195]  Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
-               for Simple Challenge/Response", RFC 2195, MCI, September
-               1997.
+   (RFC Editor: Please delete everything after this point)
 
-    [RFC2202]  Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
-               RFC 2202, IBM, September 1997
+   Open Issues
 
-    [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
-               Specification Version 2.0", RFC 2898, September 2000.
+   o  The appendices need to be written.
 
-    [TLS]  Dierks, Rescorla, "The Transport Layer Security (TLS)
-               Protocol, Version 1.2", RFC 5246, August 2008.
+   o  Should the server send a base64-encoded ServerSignature for the
+      value of the "v" attribute, or should it compute a ServerProof the
+      way the client computes a ClientProof?
 
-    [RFC4949]  Shirey, "Internet Security Glossary, Version 2", RFC
-               4949, FYI 0036, August 2007.
+   Changes since -10
 
-    [RFC4086]  Eastlake, Schiller, Crocker, "Randomness Requirements for
-               Security", RFC 4086, BCP 0106, Motorola Laboratories,
-               June 2005.
+   o  Converted the source for this I-D to XML.
 
-    [RFC4510]  Zeilenga, "Lightweight Directory Access Protocol (LDAP):
-               Technical Specification Road Map", RFC 4510, June 2006.
+   o  Added text to make SCRAM compliant with the new GS2 design.
 
-    [DIGEST-MD5] Leach, P.  and C.  Newman , "Using Digest
-    Authentication as a SASL Mechanism", RFC 2831, May 2000.  <<Also
-    draft- ietf-sasl-rfc2831bis-12.txt>>
+   o  Added text on channel binding negotiation.
 
-    [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in
-               progress, draft-ietf-sasl-digest-to-historic-00.txt, July
-               2008
+   o  Added text on channel binding, including a reference to RFC5056.
 
-    [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress,
-               draft-ietf-sasl-crammd5-to-historic-00.txt, November
-               2008.
+   o  Added text on SCRAM as a GSS-API mechanism.  This noted as not
+      relevant to SASL-only implementors -- the normative references for
+      SCRAM as a GSS-API mechanism are segregated as well.
 
-    [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security
-               Layer (SASL) Mechanism" RFC 4616, August 2006.
+   Changes since -07
 
+   o  Updated References.
 
-12.  Authors' Addresses
+   o  Clarified purpose of the m= attribute.
 
-    Abhijit Menon-Sen
-    Oryx Mail Systems GmbH
+   o  Fixed a problem with authentication/authorization identity's ABNF
+      not allowing for some characters.
 
-    Email: [e-mail]
+   o  Updated ABNF for nonce to show client-generated and server-
+      generated parts.
 
+   o  Only register SCRAM-HMAC-SHA-1 with IANA and require explicit
+      registrations of all other SCRAM-HMAC- mechanisms.
 
-    Alexey Melnikov
-    Isode Ltd
+   Changes since -06
 
-    EMail: [e-mail]
+   o  Removed hash negotiation from SCRAM and turned it into a family of
+      SASL mechanisms.
 
+   o  Start using "Hash Function Textual Names" IANA registry for SCRAM
+      mechanism naming.
 
-    Chris Newman
-    Sun Microsystems
-    1050 Lakes Drive
-    West Covina, CA 91790
-    USA
+   o  Fixed definition of Hi(str, salt) to be consistent with [RFC2898].
 
-    Email: [e-mail]
+   o  Clarified extensibility of SCRAM: added m= attribute (for future
+      mandatory extensions) and specified that all unrecognized
+      attributes must be ignored.
 
+   Changes since -05
 
-Appendix A: Other Authentication Mechanisms
+   o  Changed the mandatory to implement hash algorithm to SHA-1 (as per
+      WG consensus).
 
-    The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex
-    to implement and test, and thus has poor interoperability.  The
-    security layer is often not implemented, and almost never used;
-    everyone uses TLS instead.  For a more complete list of problems
-    with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST-
-    HISTORIC].
+   o  Added text about use of SASLPrep for username canonicalization/
+      validation.
 
-    The CRAM-MD5 SASL mechanism, while widely deployed has also some
-    problems, in particular it is missing some modern SASL features such
-    as support for internationalized usernames and passwords, support
-    for passing of authorization identity, support for channel bindings.
-    It also doesn't support server authentication.  For a more complete
-    list of problems with CRAM-MD5 see [CRAM-HISTORIC].
+   o  Clarified that authorization identity is canonicalized/verified
+      according to SASL protocol profile.
 
-    The PLAIN [PLAIN] SASL mechanism allows a malicious server or
-    eavesdropper to impersonate the authenticating user to any other
-    server for which the user has the same password.  It also sends the
-    password in the clear over the network, unless TLS is used.  Server
-    authentication is not supported.
+   o  Clarified that iteration count is per-user.
 
+   o  Clarified how clients select the authentication function.
 
-Appendix B: Design Motivations
+   o  Added IANA registration for the new mechanism.
 
-    The following design goals shaped this document.  Note that some of
-    the goals have changed since the initial version of the document.
+   o  Added missing normative references (UTF-8, SASLPrep).
 
-      The SASL mechanism has all modern SASL features: support for
-      internationalized usernames and passwords, support for passing of
-      authorization identity, support for channel bindings.
+   o  Various editorial changes based on comments from Hallvard B
+      Furuseth, Nico William and Simon Josefsson.
 
-      Both the client and server can be authenticated by the protocol.
+   Changes since -04
 
-      The authentication information stored in the authentication
-      database is not sufficient by itself to impersonate the client.
+   o  Update Base64 and Security Glossary references.
 
-      <<The server does not gain the ability to impersonate the client
-      to other servers (with an exception for server-authorized
-      proxies).>>
+   o  Add Formal Syntax section.
 
-      The mechanism is extensible, but [hopefully] not overengineered in
-      this respect.
+   o  Don't bother with "v=".
 
-      Easier to implement than DIGEST-MD5 in both clients and servers.
+   o  Make MD5 mandatory to implement.  Suggest i=128.
 
+   Changes since -03
 
-Appendix C: SCRAM Examples
+   o  Seven years have passed, in which it became clear that DIGEST-MD5
+      suffered from unacceptably bad interoperability, so SCRAM-MD5 is
+      now back from the dead.
 
-    <<To be written.>>
+   o  Be hash agnostic, so MD5 can be replaced more easily.
 
-        (RFC Editor: Please delete everything after this point)
+   o  General simplification.
 
+12.  References
 
-Open Issues
+12.1.  Normative References
 
-    o The appendices need to be written.
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
 
-    o Should the server send a base64-encoded ServerSignature for the
-      value of the "v" attribute, or should it compute a ServerProof the
-      way the client computes a ClientProof?
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
 
+   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+              (SHA1)", RFC 3174, September 2001.
 
-Changes since -07
+   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
+              Internationalized Strings ("stringprep")", RFC 3454,
+              December 2002.
 
-    Updated References.
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
 
-    Clarified purpose of the m= attribute.
+   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+              and Passwords", RFC 4013, February 2005.
 
-    Fixed a problem with authentication/authorization identity's ABNF
-      not allowing for some characters.
+   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
+              Security Layer (SASL)", RFC 4422, June 2006.
 
-    Updated ABNF for nonce to show client-generated and server-generated
-      parts.
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
 
-    Only register SCRAM-HMAC-SHA-1 with IANA and require explicit
-      registrations of all other SCRAM-HMAC- mechanisms.
+   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
+              Channels", RFC 5056, November 2007.
 
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
 
+12.2.  Normative References for GSS-API implementors
 
-Changes since -06
+   [RFC2743]  Linn, J., "Generic Security Service Application Program
+              Interface Version 2, Update 1", RFC 2743, January 2000.
 
-    Removed hash negotiation from SCRAM and turned it into a family of
-      SASL mechanisms.
+   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
+              Encryption for Kerberos 5", RFC 3962, February 2005.
 
-    Start using "Hash Function Textual Names" IANA registry for SCRAM
-      mechanism naming.
+   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+              Version 5 Generic Security Service Application Program
+              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+              July 2005.
 
-    Fixed definition of Hi(str, salt) to be consistent with [RFC2898].
+   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
+              Extension for the Generic Security Service Application
+              Program Interface (GSS-API)", RFC 4401, February 2006.
 
-    Clarified extensibility of SCRAM: added m= attribute (for future
-      mandatory extensions) and specified that all unrecognized
-      attributes must be ignored.
+   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the
+              Kerberos V Generic Security Service Application Program
+              Interface (GSS-API) Mechanism", RFC 4402, February 2006.
 
+12.3.  Informative References
 
+   [I-D.ietf-sasl-crammd5-to-historic]
+              Zeilenga, K., "CRAM-MD5 to Historic",
+              draft-ietf-sasl-crammd5-to-historic-00 (work in progress),
+              November 2008.
 
-Changes since -05
+   [I-D.ietf-sasl-digest-to-historic]
+              Melnikov, A., "Moving DIGEST-MD5 to Historic",
+              draft-ietf-sasl-digest-to-historic-00 (work in progress),
+              July 2008.
 
-    Changed the mandatory to implement hash algorithm to SHA-1 (as per
-      WG consensus).
+   [I-D.ietf-sasl-rfc2831bis]
+              Melnikov, A., "Using Digest Authentication as a SASL
+              Mechanism", draft-ietf-sasl-rfc2831bis-12 (work in
+              progress), March 2007.
 
-    Added text about use of SASLPrep for username
-      canonicalization/validation.
+   [RFC2195]  Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
+              AUTHorize Extension for Simple Challenge/Response",
+              RFC 2195, September 1997.
 
-    Clarified that authorization identity is canonicalized/verified
-      according to SASL protocol profile.
+   [RFC2202]  Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
+              SHA-1", RFC 2202, September 1997.
 
-    Clarified that iteration count is per-user.
+   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
+              Specification Version 2.0", RFC 2898, September 2000.
 
-    Clarified how clients select the authentication function.
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
 
-    Added IANA registration for the new mechanism.
+   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510,
+              June 2006.
 
-    Added missing normative references (UTF-8, SASLPrep).
+   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
+              Security Layer (SASL) Mechanism", RFC 4616, August 2006.
 
-    Various editorial changes based on comments from Hallvard B
-      Furuseth, Nico William and Simon Josefsson.
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
+              RFC 4949, August 2007.
 
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
 
+Authors' Addresses
 
-Changes since -04
+   Abhijit Menon-Sen
+   Oryx Mail Systems GmbH
 
-    o Update Base64 and Security Glossary references.
+   Email: [e-mail]
 
-    o Add Formal Syntax section.
 
-    o Don't bother with "v=".
+   Alexey Melnikov
+   Isode Ltd
 
-    o Make MD5 mandatory to implement.  Suggest i=128.
+   Email: [e-mail]
 
 
+   Chris Newman
+   Sun Microsystems
+   1050 Lakes Drive
+   West Covina, CA  91790
+   USA
 
-Changes since -03
+   Email: [e-mail]
 
-    o Seven years have passed, in which it became clear that DIGEST-MD5
-      suffered from unacceptably bad interoperability, so SCRAM-MD5 is
-      now back from the dead.
 
-    o Be hash agnostic, so MD5 can be replaced more easily.
+   Nicolas Williams
+   Sun Microsystems
+   5300 Riata Trace Ct
+   Austin, TX  78727
+   USA
 
-    o General simplification.
+   Email: [e-mail]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2HHXECK065053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 10:33:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2HHXErg065052; Tue, 17 Mar 2009 10:33:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 n2HHXDQH065046 for <[e-mail]>; Tue, 17 Mar 2009 10:33:13 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2HHXDPD008564 for <[e-mail]>; Tue, 17 Mar 2009 17:33:13 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2HHXDaS050389 for <[e-mail]>; Tue, 17 Mar 2009 11:33:13 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2HHGZhO027078; Tue, 17 Mar 2009 12:16:35 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2HHGZiN027077; Tue, 17 Mar 2009 12:16:35 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Mar 2009 12:16:34 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: New GS2: pulling everything together
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 17, 2009 at 01:15:16PM -0400, Jeffrey Hutzelman wrote:
> --On Tuesday, March 17, 2009 12:16:01 PM +0100 Simon Josefsson 
> <[e-mail]> wrote:
> 
> >To avoid this, it seems another GSS-API function such as
> >GSS_Inquire_mech_for_SASLname that return a mech OID for a given SASL
> >name, is needed.  Thoughts on whether this is worthwhile?
> 
> You could have such a function, but it wouldn't be any more efficient than 
> iterating over all of the mechanisms and computing the generated names, 
> since a hash function is used in the name generation.

But it'd be a libgss implementation detail (it can cache the computed
names, persistently even).  It's a utility function, and there's no
reason not to have it (we should also have an _init/_update/_final
variant of gss_pseudo_random() -- can't believe we didn't do that).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2HHFY12063586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 10:15:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2HHFYWX063585; Tue, 17 Mar 2009 10:15:34 -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 n2HHFM06063572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 17 Mar 2009 10:15:33 -0700 (MST) (envelope-from [e-mail])
Received: from 173-115-106-206.pools.spcsdns.net (72-59-237-76.pools.spcsdns.net [72.59.237.76]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n2HHFGYL002150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 13:15:19 -0400 (EDT)
Date: Tue, 17 Mar 2009 13:15:16 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: New GS2: pulling everything together
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [e-mail]
Precedence: 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, March 17, 2009 12:16:01 PM +0100 Simon Josefsson 
<[e-mail]> wrote:

> To avoid this, it seems another GSS-API function such as
> GSS_Inquire_mech_for_SASLname that return a mech OID for a given SASL
> name, is needed.  Thoughts on whether this is worthwhile?

You could have such a function, but it wouldn't be any more efficient than 
iterating over all of the mechanisms and computing the generated names, 
since a hash function is used in the name generation.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2HFBZEo054880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 08:11:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2HFBZpg054879; Tue, 17 Mar 2009 08:11: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-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 n2HFBNg1054856 for <[e-mail]>; Tue, 17 Mar 2009 08:11:34 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2HFBNdG025351 for <[e-mail]>; Tue, 17 Mar 2009 15:11:23 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 n2HFBNn3039797 for <[e-mail]>; Tue, 17 Mar 2009 09:11:23 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2HF2C3t026954; Tue, 17 Mar 2009 10:02:12 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2HF28dR026953; Tue, 17 Mar 2009 10:02:08 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 17 Mar 2009 10:02:08 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: New GS2: pulling everything together
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 17, 2009 at 12:16:01PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > We've had a lot of comments on the new GS2 design.  Time to pull
> > everything together again.
> 
> Good summary!

Thanks!

> I have one question/observation about GS2 for non-SCRAM mechanisms and
> header compression:
> 
> >     - The RFC2743 section 3.1 initial context token header compression
> >       flag would not be needed for a pure SASL SCRAM.  But it's only a
> >       constant for SCRAM, therefore it's not a problem.  I believe we
> >       have consensus on this.
> 
> If a server advertise a GS2 SASL mech, that doesn't have a "simple"
> name, GS2 clients (that use a GSS-API library) will need to iterate over
> all the GSS-API mechanisms supported by the GSS-API library, and compute
> the generated SASL mech name and compare that with the server mech list
> before it knows whether it supports an offered mechanism or not.  Is my
> understanding right?  It seems somewhat sub-optimal, but I don't see how
> we can avoid it.
> 
> To avoid this, it seems another GSS-API function such as
> GSS_Inquire_mech_for_SASLname that return a mech OID for a given SASL
> name, is needed.  Thoughts on whether this is worthwhile?

Sure.

BTW, the RFC2743 header compression constant could even be removed in
the case of SCRAM (since the CB flag will make it unabiguously clear
that the header compression flag had to have the sense that indicates
that the RFC2743 header should have been present).  I.e., the ABNF for
the GS2 header could be:

gs2-header = [ "F" ] ( "n" / "y" / "p" ) [ "a=" saslname ] ","

> >  - With regards to the two mechname + gs2-cb-flag approach to negotiable
> >    channel binding:
> ...
> >     - Kurt prefers this approach to doing the negotiation in the mech
> 
> I prefer it as well.  Sub-negotiation adds complexity.

I agree in general.  In this specific case I'm not sure your comment
about complexity applies, but I prefer it in this specific case as well.

> >     - Jeff and I believe this approach is simple enough.  We can't make
> >       CB negotiation in GS2 any simpler.  I believe Sam and Simon agree.
> 
> As far as I understand so far, I agree fully.

Thanks.

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 n2HBGIt3038347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 04:16:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2HBGIjG038346; Tue, 17 Mar 2009 04:16:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-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 n2HBG5U1038325 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 17 Mar 2009 04:16:17 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LjXH8-0003r2-HI; Tue, 17 Mar 2009 12:16:03 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail]
Subject: Re: New GS2: pulling everything together
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090317:[e-mail]::NtjznTciF72VTa2R:0+J3
X-Hashcash: 1:22:090317:[e-mail]::zq1fUmoNFWSMKzr8:NMOa
Date: Tue, 17 Mar 2009 12:16:01 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 16 Mar 2009 13:25:02 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> We've had a lot of comments on the new GS2 design.  Time to pull
> everything together again.

Good summary!

I have one question/observation about GS2 for non-SCRAM mechanisms and
header compression:

>     - The RFC2743 section 3.1 initial context token header compression
>       flag would not be needed for a pure SASL SCRAM.  But it's only a
>       constant for SCRAM, therefore it's not a problem.  I believe we
>       have consensus on this.

If a server advertise a GS2 SASL mech, that doesn't have a "simple"
name, GS2 clients (that use a GSS-API library) will need to iterate over
all the GSS-API mechanisms supported by the GSS-API library, and compute
the generated SASL mech name and compare that with the server mech list
before it knows whether it supports an offered mechanism or not.  Is my
understanding right?  It seems somewhat sub-optimal, but I don't see how
we can avoid it.

To avoid this, it seems another GSS-API function such as
GSS_Inquire_mech_for_SASLname that return a mech OID for a given SASL
name, is needed.  Thoughts on whether this is worthwhile?

>  - With regards to the two mechname + gs2-cb-flag approach to negotiable
>    channel binding:
...
>     - Kurt prefers this approach to doing the negotiation in the mech

I prefer it as well.  Sub-negotiation adds complexity.

>     - Jeff and I believe this approach is simple enough.  We can't make
>       CB negotiation in GS2 any simpler.  I believe Sam and Simon agree.

As far as I understand so far, I agree fully.

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 n2GIYNjx083485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2009 11:34:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2GIYMmt083484; Mon, 16 Mar 2009 11:34:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2GIYB7R083464 for <[e-mail]>; Mon, 16 Mar 2009 11:34:22 -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 n2GIYBmP011732 for <[e-mail]>; Mon, 16 Mar 2009 18:34:11 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2GIYBwh028906 for <[e-mail]>; Mon, 16 Mar 2009 12:34:11 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2GIP3p4026369 for <[e-mail]>; Mon, 16 Mar 2009 13:25:03 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2GIP2Fb026368 for [e-mail]; Mon, 16 Mar 2009 13:25:02 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 16 Mar 2009 13:25:02 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: New GS2: pulling everything together
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We've had a lot of comments on the new GS2 design.  Time to pull
everything together again.

The new design then consists of:

1) An all-text header prefixed to the client's first authentication
   message and to the application's channel binding (CB) data.

   This header consists of:

   a) a constant for RFC2743 section 3.1 initial context token header
      compression;
   b) a flag for channel binding (see below);
   c) the authzid (because the GSS-API has no equivalent).

   ABNF:

    gs2-rfc2743-compress-flag = "T" / "F"
    gs2-cb-flag = "n" / "y" / "p"
	; 'n' -> client can't and didn't do channel binding
	; 'y' -> client can do CB, but didn't
	; 'p' -> client did channel binding
    gs2-authzid = "a=" saslname ","
	; See SCRAM for definition of saslname

2) No sec layers.

3) Pretty SASL mechnames for GS2.  These must be specified/registered
   when a GSS-API mech is created (all existing standard GSS mechs will
   get one through GS2).  See below.

4) Negotiable channel binding with downgrade detection using mechanism
   name negotiation as a building block for channel binding negotiation.

   Two mechnames are needed for GS2/SCRAM:

    - SCRAM-SHA-1-PLUS
    - SCRAM-SHA-1

   Servers that support channel binding advertise both.  Servers that
   don't support CB advertise only SCRAM-SHA-1.

   The client picks SCRAM-SHA-1-PLUS if advertised, else it picks
   SCRAM-SHA-1, OR, if the client doesn't list server mechs, then it
   picks SCRAM-SHA-1 (and never sets gs2-cb-flag == "y").  The client
   also indicates, in its GS2 first message header, whether it supports
   and/or used channel binding.

   If the client sets its gs2-cb-flag == "y" and the server can do CB
   then authentication fails.

   Note that the two mechanism scheme does not imply any changes to the
   SASL APIs that weren't already implied by the pure SASL SCRAM.  The
   client and server SASL APIs require two additional application
   inputs: a) whether the application and TLS stack support channel
   binding, b) channel binding data from TLS.


ANALYSIS:

 - With regards to the GS2 first client message header:

    - The RFC2743 section 3.1 initial context token header compression
      flag would not be needed for a pure SASL SCRAM.  But it's only a
      constant for SCRAM, therefore it's not a problem.  I believe we
      have consensus on this.

    - The authzid would be lifted out of SCRAM and into the GS2 header.
      This neither adds nor removes complexity and so should not, I
      think, be objectionable.

    - The channel binding flag would be needed inside a pure SASL SCRAM
      anyways, therefore, I think, it should not be objectionable.

 - With regards to the two mechname + gs2-cb-flag approach to negotiable
   channel binding:

    - Client apps that don't negotiate SASL mechs can't negotiate
      channel binding -- they can try it, and authentication will fail
      if the server can't do CB (the client can always re-try).

    - Kurt prefers this approach to doing the negotiation in the mech

    - Chris had comments, but I think those are now satisfied.

    - Jeff and I believe this approach is simple enough.  We can't make
      CB negotiation in GS2 any simpler.  I believe Sam and Simon agree.

    - We need input from the rest of the SASL WG on this.  This is the
      last open issue for the new GS2 design.

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 n2CHuXab004779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 10:56:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CHuXWh004778; Thu, 12 Mar 2009 10:56:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-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 n2CHuMaw004767 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 12 Mar 2009 10:56:32 -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 n2CHu9C2024872 for <[e-mail]>; Thu, 12 Mar 2009 10:56:22 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; format=flowed; charset=us-ascii
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <[e-mail]> for [e-mail]; Thu, 12 Mar 2009 10:56:09 -0700 (PDT)
Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <[e-mail]>; Thu, 12 Mar 2009 10:56:03 -0700 (PDT)
Date: Thu, 12 Mar 2009 10:56:00 -0700
From: Chris Newman <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-reply-to: <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>, Nicolas Williams <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Dave Cridland <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0FE4E16CFFB0F9824225E81D@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <9F2EBABF98B5CD1145234E9D@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>

Sounds good to me.

		- Chris

--On March 12, 2009 8:02:15 -0400 Jeffrey Hutzelman <[e-mail]> wrote:

> --On Wednesday, March 11, 2009 06:42:38 PM -0800 Chris Newman
> <[e-mail]> wrote:
>
>> --On March 6, 2009 0:15:30 -0600 Nicolas Williams
>> <[e-mail]> wrote:
>>> Ah, right.  The server must advertise only one or the other of the two
>>> names, never both as it's the client's choice of mech name that will
>>> tip off the server to any MITMs.
>>
>> As I stated in my previous message, I believe the one-or-the-other
>> mechanism name creates an interoperability problem.  If that is WG
>> consensus, I will likely only implement the non-channel-binding variant
>> as I know all SCRAM software will support that variant.  If I were to add
>> server support for the channel binding variant, that probably would break
>> interoperability with a client that does not understand the
>> channel-binding-name variant.  I don't think that's a good outcome as it
>> sabotages deployment of channel bindings.
>>
>> There is a flag which indicates "server can do TLS and has access to TLS
>> channel bindings".  It is my belief this flag needs to appear both in the
>> mechanism name and in the authentication mechanism itself.  The former is
>> used by the client to select the appropriate mechanism and the latter can
>> be used by the client to detect a downgrade attack.
>>
>> The result is we have two mechanisms that have identical bits-on-the-wire
>> just different names.  I'll call them SCRAM-SHA1 and SCRAM-SHA1-PLUS for
>> now.
>>
>> Case 1: server supports channel bindings.
>>
>> Server advertises both mechanisms.  Client may negotiate either mechanism
>> and use channel bindings with either mechanism if it wishes.  If client
>> policy requires channel bindings it will ignore SCRAM-SHA1 and only
>> negotiate SCRAM-SHA1-PLUS.
>>
>> Case 2: server does not support channel bindings
>>
>> Server advertises only SCRAM-SHA1.  SCRAM-SHA1 includes flag indicating
>> lack of server channel bindings.  If client selects SCRAM-SHA1 and
>> attempts to use channel bindings, authentication will fail.  Client may
>> choose a mechanism other than SCRAM-SHA1 due to lack of server channel
>> binding support that is detectable at mechanism name negotiation time.
>>
>> Case 3: downgrade attack.
>>
>> Server advertises both names.  Client sees only SCRAM-SHA1, selects it
>> and notices the server does support channel bindings.  If client supports
>> channel bindings, it will see the flag indicating server support for
>> channel bindings and either fail with MITM error then or negotiate
>> channel bindings on and channel binding will fail due to MITM.  If MITM
>> changed the flag, authentication will fail because the flag is included
>> in the authentication hash.  If client does not support channel bindings,
>> it proceeds as usual (although there is a sub-case it can detect that's
>> no point doing so as the client policy permits MITMs in this case).
>>
>> This approach does not create an interop problem and I suspect the code
>> will be simpler on both ends than it would be with an either-or naming
>> model.
>
> Yes, I think that would work.
>
> Thinking about this a bit more, ideally, neither a SASL framework library
> nor an application which uses such a library should need to know more
> than is absolutele necessary about the special relationship between these
> mechanism names.  Ideally, correct behavior should be achievable through
> a combination of three things:
>
> - An interface which allows the application to pass channel bindings to
>   SASL, and for the framework and mechanism to tell whether they were
>   given.  I think this is necessary no matter what negotation model we
>   end up with.
>
> - Some way for the framework to know which mechanisms _require_ channel
>   bindings.  For negotiation to select the correct mechanism in all cases,
>   SCRAM-SHA1-PLUS must be considered such a mechanism, though I believe
>   that in practice it will interoperate correctly even if this mechanism
>   is used without channel bindings.
>
> - Configuration, presumably provided by the user/administrator, which
>   what mechanisms are used and in what preference order.
>
> If client has CB:
>   Case 1: server advertises + and -, client prefers +   => + with CB
>   Case 2: server advertises - only, client negotates -  => - with no CB
>   Case 3: server advertises + and -, client negotates - => - with no CB
>           ... but downgrade is detected
>
> If client has no CB:
>   server advertises whatever; client negotiates -       => - with no CB
>
> If client requires CB:
>   Case 1: server advertises + and -, client requires +  => + with CB
>   Case 2: server advertises - only, client requires +   => fail
>
>
> Given the model you describe, this means clients should be configured to
> prefer SCRAM-SHA1-PLUS over SCRAM-SHA1, unless policy requires the use of
> channel bindings, in which case they should be configured to use only
> SCRAM-SHA1-PLUS.  This will result in negotiation of SCRAM-SHA1-PLUS
> whenever channel bindings should be used, and SCRAM-SHA1 when they should
> not; the mechanism decides whether to send CB depending on which
> mechanism name was used.  Note that this means we no longer need to send
> a separate bit indicating whether CB were used, since that is now implied
> by the mechanism name.
>
> For downgrade detection, the client needs to send an additional bit of
> authenticated information.  In the proposal Nico originally posted, this
> was the client's idea of whether the server had advertised CB support
> (via the mechanism name); if this was clear but the server actually did
> advertise CB support, then a downgrade had been attempted.  Under your
> model, this bit indicates whether the client supports CB.  If it is set,
> and the server also supports CB, but they were not used, then there is a
> downgrade.
>
> It is necessary for the downgrade-detection bit to be set from the client
> to the server, not the other way around, because detection depends on
> this bit being authenticated, and security depends on the downgrade being
> detected before the server considers authentication successful.  Suppose
> the server advertises CB support, an attacker suppressed that bit, and so
> the client chooses SCRAM without CB.  They then carry out an
> authentication exchange, during which the server claims to support CB,
> but the attacker modifies _that_ claim, so that again the server appears
> not to support CB. Now, the client will eventually figure that out, when
> the server's final response doesn't verify, but by then it is too late --
> the server has already accepted the authentication, and the MiTM controls
> a connection to the server authenticated as the client.
>
> -- 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 n2CC2fbj079843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 05:02:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2CC2eJg079842; Thu, 12 Mar 2009 05:02:40 -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 n2CC2SsN079816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 12 Mar 2009 05:02:39 -0700 (MST) (envelope-from [e-mail])
Received: from 68-246-236-206.pools.spcsdns.net (68-246-236-206.pools.spcsdns.net [68.246.236.206]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n2CC2JNU012715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2009 08:02:21 -0400 (EDT)
Date: Thu, 12 Mar 2009 08:02:15 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Chris Newman <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Dave Cridland <[e-mail]>, [e-mail], [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <9F2EBABF98B5CD1145234E9D@446E7922C82D299DB29D899F>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0FE4E16CFFB0F9824225E81D@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <9F2EBABF98B5CD1145234E9D@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, March 11, 2009 06:42:38 PM -0800 Chris Newman 
<[e-mail]> wrote:

> --On March 6, 2009 0:15:30 -0600 Nicolas Williams
> <[e-mail]> wrote:
>> Ah, right.  The server must advertise only one or the other of the two
>> names, never both as it's the client's choice of mech name that will
>> tip off the server to any MITMs.
>
> As I stated in my previous message, I believe the one-or-the-other
> mechanism name creates an interoperability problem.  If that is WG
> consensus, I will likely only implement the non-channel-binding variant
> as I know all SCRAM software will support that variant.  If I were to add
> server support for the channel binding variant, that probably would break
> interoperability with a client that does not understand the
> channel-binding-name variant.  I don't think that's a good outcome as it
> sabotages deployment of channel bindings.
>
> There is a flag which indicates "server can do TLS and has access to TLS
> channel bindings".  It is my belief this flag needs to appear both in the
> mechanism name and in the authentication mechanism itself.  The former is
> used by the client to select the appropriate mechanism and the latter can
> be used by the client to detect a downgrade attack.
>
> The result is we have two mechanisms that have identical bits-on-the-wire
> just different names.  I'll call them SCRAM-SHA1 and SCRAM-SHA1-PLUS for
> now.
>
> Case 1: server supports channel bindings.
>
> Server advertises both mechanisms.  Client may negotiate either mechanism
> and use channel bindings with either mechanism if it wishes.  If client
> policy requires channel bindings it will ignore SCRAM-SHA1 and only
> negotiate SCRAM-SHA1-PLUS.
>
> Case 2: server does not support channel bindings
>
> Server advertises only SCRAM-SHA1.  SCRAM-SHA1 includes flag indicating
> lack of server channel bindings.  If client selects SCRAM-SHA1 and
> attempts to use channel bindings, authentication will fail.  Client may
> choose a mechanism other than SCRAM-SHA1 due to lack of server channel
> binding support that is detectable at mechanism name negotiation time.
>
> Case 3: downgrade attack.
>
> Server advertises both names.  Client sees only SCRAM-SHA1, selects it
> and notices the server does support channel bindings.  If client supports
> channel bindings, it will see the flag indicating server support for
> channel bindings and either fail with MITM error then or negotiate
> channel bindings on and channel binding will fail due to MITM.  If MITM
> changed the flag, authentication will fail because the flag is included
> in the authentication hash.  If client does not support channel bindings,
> it proceeds as usual (although there is a sub-case it can detect that's
> no point doing so as the client policy permits MITMs in this case).
>
> This approach does not create an interop problem and I suspect the code
> will be simpler on both ends than it would be with an either-or naming
> model.

Yes, I think that would work.

Thinking about this a bit more, ideally, neither a SASL framework library 
nor an application which uses such a library should need to know more than 
is absolutele necessary about the special relationship between these 
mechanism names.  Ideally, correct behavior should be achievable through a 
combination of three things:

- An interface which allows the application to pass channel bindings to
  SASL, and for the framework and mechanism to tell whether they were
  given.  I think this is necessary no matter what negotation model we
  end up with.

- Some way for the framework to know which mechanisms _require_ channel
  bindings.  For negotiation to select the correct mechanism in all cases,
  SCRAM-SHA1-PLUS must be considered such a mechanism, though I believe
  that in practice it will interoperate correctly even if this mechanism
  is used without channel bindings.

- Configuration, presumably provided by the user/administrator, which
  what mechanisms are used and in what preference order.

If client has CB:
  Case 1: server advertises + and -, client prefers +   => + with CB
  Case 2: server advertises - only, client negotates -  => - with no CB
  Case 3: server advertises + and -, client negotates - => - with no CB
          ... but downgrade is detected

If client has no CB:
  server advertises whatever; client negotiates -       => - with no CB

If client requires CB:
  Case 1: server advertises + and -, client requires +  => + with CB
  Case 2: server advertises - only, client requires +   => fail


Given the model you describe, this means clients should be configured to 
prefer SCRAM-SHA1-PLUS over SCRAM-SHA1, unless policy requires the use of 
channel bindings, in which case they should be configured to use only 
SCRAM-SHA1-PLUS.  This will result in negotiation of SCRAM-SHA1-PLUS 
whenever channel bindings should be used, and SCRAM-SHA1 when they should 
not; the mechanism decides whether to send CB depending on which mechanism 
name was used.  Note that this means we no longer need to send a separate 
bit indicating whether CB were used, since that is now implied by the 
mechanism name.

For downgrade detection, the client needs to send an additional bit of 
authenticated information.  In the proposal Nico originally posted, this 
was the client's idea of whether the server had advertised CB support (via 
the mechanism name); if this was clear but the server actually did 
advertise CB support, then a downgrade had been attempted.  Under your 
model, this bit indicates whether the client supports CB.  If it is set, 
and the server also supports CB, but they were not used, then there is a 
downgrade.

It is necessary for the downgrade-detection bit to be set from the client 
to the server, not the other way around, because detection depends on this 
bit being authenticated, and security depends on the downgrade being 
detected before the server considers authentication successful.  Suppose 
the server advertises CB support, an attacker suppressed that bit, and so 
the client chooses SCRAM without CB.  They then carry out an authentication 
exchange, during which the server claims to support CB, but the attacker 
modifies _that_ claim, so that again the server appears not to support CB. 
Now, the client will eventually figure that out, when the server's final 
response doesn't verify, but by then it is too late -- the server has 
already accepted the authentication, and the MiTM controls a connection to 
the server authenticated as the client.

-- 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 n2C1h67H049639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 18: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 n2C1h6MR049638; Wed, 11 Mar 2009 18: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 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 n2C1gtRN049601 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 11 Mar 2009 18:43:05 -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 n2C1ggi7026893 for <[e-mail]>; Wed, 11 Mar 2009 18:42:54 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; format=flowed; charset=us-ascii
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <[e-mail]> for [e-mail]; Wed, 11 Mar 2009 18:42:42 -0700 (PDT)
Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <[e-mail]>; Wed, 11 Mar 2009 18:42:41 -0700 (PDT)
Date: Wed, 11 Mar 2009 18:42:38 -0800
From: Chris Newman <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-reply-to: <[e-mail]>
To: Nicolas Williams <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Dave Cridland <[e-mail]>, [e-mail]
Message-id: <9F2EBABF98B5CD1145234E9D@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0FE4E16CFFB0F9824225E81D@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 March 6, 2009 0:15:30 -0600 Nicolas Williams 
<[e-mail]> wrote:
> Ah, right.  The server must advertise only one or the other of the two
> names, never both as it's the client's choice of mech name that will
> tip off the server to any MITMs.

As I stated in my previous message, I believe the one-or-the-other 
mechanism name creates an interoperability problem.  If that is WG 
consensus, I will likely only implement the non-channel-binding variant as 
I know all SCRAM software will support that variant.  If I were to add 
server support for the channel binding variant, that probably would break 
interoperability with a client that does not understand the 
channel-binding-name variant.  I don't think that's a good outcome as it 
sabotages deployment of channel bindings.

There is a flag which indicates "server can do TLS and has access to TLS 
channel bindings".  It is my belief this flag needs to appear both in the 
mechanism name and in the authentication mechanism itself.  The former is 
used by the client to select the appropriate mechanism and the latter can 
be used by the client to detect a downgrade attack.

The result is we have two mechanisms that have identical bits-on-the-wire 
just different names.  I'll call them SCRAM-SHA1 and SCRAM-SHA1-PLUS for 
now.

Case 1: server supports channel bindings.

Server advertises both mechanisms.  Client may negotiate either mechanism 
and use channel bindings with either mechanism if it wishes.  If client 
policy requires channel bindings it will ignore SCRAM-SHA1 and only 
negotiate SCRAM-SHA1-PLUS.

Case 2: server does not support channel bindings

Server advertises only SCRAM-SHA1.  SCRAM-SHA1 includes flag indicating 
lack of server channel bindings.  If client selects SCRAM-SHA1 and attempts 
to use channel bindings, authentication will fail.  Client may choose a 
mechanism other than SCRAM-SHA1 due to lack of server channel binding 
support that is detectable at mechanism name negotiation time.

Case 3: downgrade attack.

Server advertises both names.  Client sees only SCRAM-SHA1, selects it and 
notices the server does support channel bindings.  If client supports 
channel bindings, it will see the flag indicating server support for 
channel bindings and either fail with MITM error then or negotiate channel 
bindings on and channel binding will fail due to MITM.  If MITM changed the 
flag, authentication will fail because the flag is included in the 
authentication hash.  If client does not support channel bindings, it 
proceeds as usual (although there is a sub-case it can detect that's no 
point doing so as the client policy permits MITMs in this case).

This approach does not create an interop problem and I suspect the code 
will be simpler on both ends than it would be with an either-or naming 
model.

		- 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 n2BMGuVG042314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 15:16:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2BMGuZ6042313; Wed, 11 Mar 2009 15:16:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n2BMGipo042305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Mar 2009 15:16:55 -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 n2BMGgvJ001988 for <[e-mail]>; Wed, 11 Mar 2009 18:16:42 -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 n2BMGfuf001309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 11 Mar 2009 18:16:41 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n2BMGeh5012034; Wed, 11 Mar 2009 18:16:40 -0400 (EDT)
To: [e-mail]
Subject: Re: agenda items for ietf74?
References: <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Wed, 11 Mar 2009 18:16:40 -0400
In-Reply-To: <[e-mail]> (Tom Yu's message of "Wed, 11 Mar 2009 11:39:16 -0400")
Message-ID: <[e-mail]>
Lines: 5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I uploaded the draft agenda:

http://www.ietf.org/proceedings/09mar/agenda/sasl.txt

Please send any proposed revisions by the end of this week.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2BFdWNL020910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 08: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 n2BFdW5d020909; Wed, 11 Mar 2009 08: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 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 n2BFdKEm020893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 11 Mar 2009 08:39:31 -0700 (MST) (envelope-from [e-mail])
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n2BFdHpZ011799 for <[e-mail]>; Wed, 11 Mar 2009 11:39:18 -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 n2BFdG1H015006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 11 Mar 2009 11:39:17 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n2BFdGXS010610; Wed, 11 Mar 2009 11:39:16 -0400 (EDT)
To: [e-mail]
Subject: agenda items for ietf74?
From: Tom Yu <[e-mail]>
Date: Wed, 11 Mar 2009 11:39:16 -0400
Message-ID: <[e-mail]>
Lines: 3
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>

We have 2.5 hours Tuesday morning.  Hopefully we do not require all of
that time to talk about SCRAM/GS2.  Are there any other suggestios for
agenda items?  The draft WG agendas are due today.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AJ49GV051407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 12:04:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AJ49jr051406; Tue, 10 Mar 2009 12:04:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 n2AJ3vfh051392 for <[e-mail]>; Tue, 10 Mar 2009 12:04:07 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2AJ3vX4009892 for <[e-mail]>; Tue, 10 Mar 2009 19:03:57 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 n2AJ3uU6040653 for <[e-mail]>; Tue, 10 Mar 2009 13:03:56 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2AIsppB020290; Tue, 10 Mar 2009 13:54:51 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2AIskAI020289; Tue, 10 Mar 2009 13:54:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Mar 2009 13:54:46 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <Zz/Gxv9Zkapgqlmh+TtO/[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, Mar 10, 2009 at 07:48:05PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > On Tue, Mar 10, 2009 at 10:46:42AM +0100, Arnt Gulbrandsen wrote:
> >> IMO we're better of with two values: A recommended default with vague 
> >> language like "increase this by 15% per year", and a fixed minimum.
> >
> > A minimum iteration count protects the client from downgrade attacks.
> >
> > But when SCRAM is used with channel binding, as it ought to be, the
> > iteration count need only be high enough to prevent real-time, online
> > dictionary attacks.
> 
> Consider active attackers with offline dictionary attack ability.  Do a
> MITM on one connection, get a SCRAM exchange, then go at the exchange
> using your dictionary.  Return when you have found the password.

Correct, the "high enough to prevent real-time" attacks rule has to be
combined with heuristic detection of MITMs in the case that the server
fails to complete the SCRAM authentication exchange.

In the case of TLS w/o server certs that means every such failure has to
be treated as equivalent to handing an attacker material that can be
attacked off-line.

In the case of TLS w/ server certs a subsequent successful
authentication with channel binding means that the previous failure is
not a problem.

But I think the rest of this thread has brought us to a consensus: a
high iteration count is not a problem for mobile devices, particularly
provided that they can cache the PBKDF2 results.

So I think there's no need to distinguish CB and non-CB cases when it
comes to minimum iteration count.

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 n2AImD6E050486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 11:48:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AImDFe050485; Tue, 10 Mar 2009 11:48: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 n2AImB4A050479 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Mar 2009 11:48:12 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lh6zm-0005tR-TW; Tue, 10 Mar 2009 19:48:07 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <Zz/Gxv9Zkapgqlmh+TtO/[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090310:[e-mail]::72F2HG3FAkZE6t/+:HEQg
X-Hashcash: 1:22:090310:[e-mail]::dCMjX3tfyPUbTg8b:KZbd
X-Hashcash: 1:22:090310:[e-mail]::/FCSrxp0Ckl3SEGx:fg7p
Date: Tue, 10 Mar 2009 19:48:05 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 10 Mar 2009 12:32:56 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Mar 10, 2009 at 10:46:42AM +0100, Arnt Gulbrandsen wrote:
>> IMO we're better of with two values: A recommended default with vague 
>> language like "increase this by 15% per year", and a fixed minimum.
>
> A minimum iteration count protects the client from downgrade attacks.
>
> But when SCRAM is used with channel binding, as it ought to be, the
> iteration count need only be high enough to prevent real-time, online
> dictionary attacks.

Consider active attackers with offline dictionary attack ability.  Do a
MITM on one connection, get a SCRAM exchange, then go at the exchange
using your dictionary.  Return when you have found the password.

Given that a failed connection attempt are likely not noticed by the
majority of users, if it only happens once in a while, I think this is a
realistic scenario.

Whether it is worth worrying about is another question, but increasing
the minimum iteration count helps to mitigate this type of attack.

/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 n2AIgxu5050150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 11:42:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AIgxT9050149; Tue, 10 Mar 2009 11:42:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AIgvH0050142 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Mar 2009 11:42:58 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lh6ul-0005tK-Gj; Tue, 10 Mar 2009 19:42:56 +0100
X-Hashcash: 1:22:090310:[e-mail]::eX/GZQwMnyARS9gH:02P5
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Tony Finch <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090310:[e-mail]::QMZDHPThLhj1CaNn:01YL
X-Hashcash: 1:22:090310:[e-mail]::SBeQNUlj73pampCZ:27U2
X-Hashcash: 1:22:090310:[e-mail]::AMPGA+nOjUNwvnqe:G1WV
X-Hashcash: 1:22:090310:[e-mail]::h8nueFZywfTgUjdj:egjq
Date: Tue, 10 Mar 2009 19:42:54 +0100
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 10 Mar 2009 10:29:07 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On Mar 10, 2009, at 10:19 AM, Simon Josefsson wrote:
>
>> I don't think we can assume all servers will store hashed passwords.
>
> I agree.  Storing the actual password is common when the servers
> support a wide range of password-based authentication mechanisms.

Right.

>> There are many deployments where passwords are stored in separate
>> databases.  I would be surprised if all implementations supports
>> stored
>> hashed passwords.
>>
>> This means that we will see servers that use a random salt in SCRAM on
>> every connection.
>
> Or possibly separately store (per user) the salt they use for SCRAM.

I don't think we can assume that all servers are able to do this either.

>> If we don't want this, the protocol needs to require that servers
>> store
>> hashed passwords and explain the problem that happens otherwise.
>
> I would oppose this as there is a general need to support a wide range
> of password-based authentication mechanisms.

I agree.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AHuP8j046800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 10:56:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AHuP25046799; Tue, 10 Mar 2009 10:56:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AHuDZ8046782 for <[e-mail]>; Tue, 10 Mar 2009 10:56:24 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 57F1C4AC5B; Tue, 10 Mar 2009 18:56:12 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1236707772-87767-1/6/11 (2 recipients); Tue, 10 Mar 2009 18:56:12 +0100
Message-Id: <[e-mail]>
Date: Tue, 10 Mar 2009 18:54:46 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> This means that we will see servers that use a random salt in SCRAM on 
> every connection.

Or that derive the salt from e.g. the user name and a per-installation 
constant, as Dave suggested.

Anyway it's just a quality-of-service matter, and one that applies only 
to battery-powered clients.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AHgHLT045603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 10: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 n2AHgHCJ045602; Tue, 10 Mar 2009 10: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 brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AHg5Eo045589 for <[e-mail]>; Tue, 10 Mar 2009 10:42:16 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2AHg5h9026405 for <[e-mail]>; Tue, 10 Mar 2009 17:42:05 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2AHg5IK014185 for <[e-mail]>; Tue, 10 Mar 2009 11:42:05 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2AHWv2o020255; Tue, 10 Mar 2009 12:32:57 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2AHWu4C020254; Tue, 10 Mar 2009 12:32:56 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 10 Mar 2009 12:32:56 -0500
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <Zz/Gxv9Zkapgqlmh+TtO/[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zz/Gxv9Zkapgqlmh+TtO/[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 10, 2009 at 10:46:42AM +0100, Arnt Gulbrandsen wrote:
> IMO we're better of with two values: A recommended default with vague 
> language like "increase this by 15% per year", and a fixed minimum.

A minimum iteration count protects the client from downgrade attacks.

But when SCRAM is used with channel binding, as it ought to be, the
iteration count need only be high enough to prevent real-time, online
dictionary attacks.  In the channel binding mode then the iteration
count can be low and may not need to grow as time passes.

We might want two minimum iteration counts then: one for the channel
binding use case and one for the non-CB use case.

The problem with "increase this by X% per year" is that that implies
re-computing and replacing the password verifier stored by the server,
so if the client were to enforce such a moving target it would get
itself locked out unless the users change their passwords periodically.

Also, I'm not sure that Moore's "law" applies to mobile devices.  The
limiting factor for mobile devices is power, or, more likely, heat
dissipation, and Moore's law doesn't really apply there.  So, though an
"increase this by X% per year" seems quite sensible from a security
p.o.v., it may not be at all from a mobile hardware p.o.v.

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 n2AHTDE3044905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 10:29:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AHTDEk044904; Tue, 10 Mar 2009 10:29: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 n2AHTBT5044896 for <[e-mail]>; Tue, 10 Mar 2009 10:29:12 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.164] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]>; Tue, 10 Mar 2009 17:29:10 +0000
Cc: Alexey Melnikov <[e-mail]>, Tony Finch <[e-mail]>, Jeffrey Hutzelman <[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: SCRAM minimum PBKDF#2 iteration count
Date: Tue, 10 Mar 2009 10:29:07 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mar 10, 2009, at 10:19 AM, Simon Josefsson wrote:

> I don't think we can assume all servers will store hashed passwords.

I agree.  Storing the actual password is common when the servers  
support a wide range of password-based authentication mechanisms.

> There are many deployments where passwords are stored in separate
> databases.  I would be surprised if all implementations supports  
> stored
> hashed passwords.
>
> This means that we will see servers that use a random salt in SCRAM on
> every connection.

Or possibly separately store (per user) the salt they use for SCRAM.

>
>
> If we don't want this, the protocol needs to require that servers  
> store
> hashed passwords and explain the problem that happens otherwise.

I would oppose this as there is a general need to support a wide range  
of password-based authentication mechanisms.


> I'm not sure it is practical to make this a MUST.  Or is there  
> already text
> in SCRAM to address 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 n2AHOKa7044573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 10:24:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AHOJjn044572; Tue, 10 Mar 2009 10:24:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AHOIcs044558 for <[e-mail]>; Tue, 10 Mar 2009 10:24:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.115] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 10 Mar 2009 17:24:15 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Mar 2009 17:23:23 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: Tony Finch <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>We want to allow servers to store hashed passwords. This means that
>>the server end dictates the minimum iteration count.
>>    
>>
>I don't think we can assume all servers will store hashed passwords.
>  
>
We shouldn't assume that, but we shouldn't preclude that either.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AHKEGt044352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 10:20:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AHKEAv044351; Tue, 10 Mar 2009 10:20:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n2AHK2EN044338 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Mar 2009 10:20:13 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lh5cS-0005sa-Hb; Tue, 10 Mar 2009 18:19:58 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Tony Finch <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090310:[e-mail]::M178+wsLF544Aey2:4feT
X-Hashcash: 1:22:090310:[e-mail]::Pmw11Uq9hOrgoirO:63Jt
X-Hashcash: 1:22:090310:[e-mail]::K3A/ZvzcrOm7CuU/:Ds8p
X-Hashcash: 1:22:090310:[e-mail]::Kn/zprjxRidNJkKG:jjxQ
Date: Tue, 10 Mar 2009 18:19:55 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Tue, 10 Mar 2009 16:04:03 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Tony Finch wrote:
>
>>On Tue, 10 Mar 2009, Alexey Melnikov wrote:
>>  
>>
>>>Besides, the iteration count can be stored together with user's secret,
>>>so it is really controlled by the server end.
>>>    
>>>
>>However note that a very large proportion of users use multiple clients of
>>varying capability, so per-user isn't fine grained enough.
>>  
>>
> Tony, I don't think doing anything more granular (i.e. per-client)
> would work.
>
> We want to allow servers to store hashed passwords. This means that
> the server end dictates the minimum iteration count.

I don't think we can assume all servers will store hashed passwords.

There are many deployments where passwords are stored in separate
databases.  I would be surprised if all implementations supports stored
hashed passwords.

This means that we will see servers that use a random salt in SCRAM on
every connection.

If we don't want this, the protocol needs to require that servers store
hashed passwords and explain the problem that happens otherwise.  I'm
not sure it is practical to make this a MUST.  Or is there already text
in SCRAM to address 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 n2AGehWx042060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 09:40:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AGehA3042059; Tue, 10 Mar 2009 09:40:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AGeVIc042039 for <[e-mail]>; Tue, 10 Mar 2009 09:40:42 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Tue, 10 Mar 2009 16:41:23 +0000
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 10 Mar 2009 16:40:22 +0000
From: Dave Cridland <[e-mail]>
To: Tony Finch <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, <[e-mail]>, Alexey Melnikov <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue Mar 10 15:31:53 2009, Tony Finch wrote:
> 
> On Tue, 10 Mar 2009, Alexey Melnikov wrote:
> >
> > Besides, the iteration count can be stored together with user's  
> secret,
> > so it is really controlled by the server end.
> 
> However note that a very large proportion of users use multiple  
> clients of
> varying capability, so per-user isn't fine grained enough.

I don't think there's a significant problem with asking a mobile or  
embedded client to do 4097 SHA-1's the first time it logs in as a  
one-off. If it were every time, it'd be a problem, sure, but it  
shouldn't need to be.

I would add that this needs not only a stable iteration count, but a  
stable salt - implementations not capable of storing a salt should  
therefore generate one using some stable algorithm (like  
H(<username>,<server hostname>,<configured constant>) or something).

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AG4ww7039800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 09:04:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AG4wrn039799; Tue, 10 Mar 2009 09:04:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AG4lMK039786 for <[e-mail]>; Tue, 10 Mar 2009 09:04:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.115] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 10 Mar 2009 16:04:44 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Mar 2009 16:04:03 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Tony Finch <[e-mail]>
CC: Simon Josefsson <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Finch wrote:

>On Tue, 10 Mar 2009, Alexey Melnikov wrote:
>  
>
>>Besides, the iteration count can be stored together with user's secret,
>>so it is really controlled by the server end.
>>    
>>
>However note that a very large proportion of users use multiple clients of
>varying capability, so per-user isn't fine grained enough.
>  
>
Tony, I don't think doing anything more granular (i.e. per-client) would 
work.

We want to allow servers to store hashed passwords. This means that the 
server end dictates the minimum iteration count.

We could extend the protocol to allow the client to say "oh, but I want 
to have an iteration count bigger than the one advertised by the 
server". But I really doubt any client would ever make use of this 
feature and so I think it adds unnecessary complexity.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AFWDXQ037564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 08:32:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AFWDdV037563; Tue, 10 Mar 2009 08:32:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AFW0QT037541 for <[e-mail]>; Tue, 10 Mar 2009 08:32:10 -0700 (MST) (envelope-from [e-mail])
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39025) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1Lh3vt-0000BE-5b (Exim 4.70) (return-path <[e-mail]>); Tue, 10 Mar 2009 15:31:53 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Lh3vt-0003SP-ND (Exim 4.67) (return-path <[e-mail]>); Tue, 10 Mar 2009 15:31:53 +0000
Date: Tue, 10 Mar 2009 15:31:53 +0000
From: Tony Finch <[e-mail]>
X-X-Sender: [e-mail]
To: Alexey Melnikov <[e-mail]>
cc: Simon Josefsson <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 10 Mar 2009, Alexey Melnikov wrote:
>
> Besides, the iteration count can be stored together with user's secret,
> so it is really controlled by the server end.

However note that a very large proportion of users use multiple clients of
varying capability, so per-user isn't fine grained enough.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ACr1R3024835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 05:53:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ACr175024834; Tue, 10 Mar 2009 05:53:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ACqmCH024814 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Mar 2009 05:53:00 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lh1Rt-00052Z-6u; Tue, 10 Mar 2009 13:52:46 +0100
From: Simon Josefsson <[e-mail]>
To: Dave Cridland <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, <[e-mail]>
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090310:[e-mail]::F/KXMqN30Y7ysU9j:0/RM
X-Hashcash: 1:22:090310:[e-mail]::dtzOXasUzhcrjcsh:2LHZ
X-Hashcash: 1:22:090310:[e-mail]::6BoElWVAuO3Y7H5P:6Zl3
Date: Tue, 10 Mar 2009 13:52:44 +0100
In-Reply-To: <[e-mail]> (Dave Cridland's message of "Tue, 10 Mar 2009 11:57:21 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland <[e-mail]> writes:

> On Mon Mar  9 21:24:33 2009, Jeffrey Hutzelman wrote:
>> Yes, there is.  A minimum value is one which must be advertised to
>> all clients, including those which are mobile devices with limited
>> processing power.  If using SCRAM makes fetching mail from a phone
>> too slow, people will just keep using PLAIN.
>
> The iteration count is only used in the generation of the actual
> shared secret from the password, though - once this is generated
> once, it can be stored for future authentications.
>
> So while it's reasonable to say that initial authentication might be
> slower (and burn battery), subsequent authentication is roughly as
> fast as CRAM-MD5, isn't it?

That assumes the server doesn't change the salt too frequently for the
particular user.  Some servers may not be able to store a salt, and may
just have access to username + password.  In this case, it would
generate a random salt on every connection.

On the other hand, I believe even 4096 hash iterations will be
sufficiently quick on any processor that is capable of implementing TLS
& SASL and a user interface.

> Given the figures Simon gave on the XMPP Security list, I think a
> recommended minimum of 4096 is reasonable.

That works for me.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ACIDRB021657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 05:18:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ACID7d021656; Tue, 10 Mar 2009 05:18:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ACICH6021650 for <[e-mail]>; Tue, 10 Mar 2009 05:18:13 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 033F64AC5B; Tue, 10 Mar 2009 13:18:11 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1236687491-87767-1/6/6 for [e-mail]; Tue, 10 Mar 2009 13:18:11 +0100
Message-Id: <[e-mail]>
Date: Tue, 10 Mar 2009 13:16:45 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland writes:
> The iteration count is only used in the generation of the actual
> shared secret from the password, though - once this is generated
> once, it can be stored for future authentications.

Oh, right.

Might be good to mention this in the RFC, though. And particularly 
mention that a cacheless server is not very friendly to battery-powered 
clients.

> So while it's reasonable to say that initial authentication might be
> slower (and burn battery), subsequent authentication is roughly as
> fast as CRAM-MD5, isn't it?
>
> Given the figures Simon gave on the XMPP Security list, I think a
> recommended minimum of 4096 is reasonable.

OK.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ABw4fs020328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 04:58:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2ABw4UR020327; Tue, 10 Mar 2009 04:58:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2ABvqKX020315 for <[e-mail]>; Tue, 10 Mar 2009 04:58:03 -0700 (MST) (envelope-from [e-mail])
Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Tue, 10 Mar 2009 11:58:39 +0000
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 10 Mar 2009 11:57:21 +0000
From: Dave Cridland <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="[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>

[e-mail]
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"

On Mon Mar  9 21:24:33 2009, Jeffrey Hutzelman wrote:
> Yes, there is.  A minimum value is one which must be advertised to  
> all clients, including those which are mobile devices with limited  
> processing power.  If using SCRAM makes fetching mail from a phone  
> too slow, people will just keep using PLAIN.

The iteration count is only used in the generation of the actual  
shared secret from the password, though - once this is generated  
once, it can be stored for future authentications.

So while it's reasonable to say that initial authentication might be  
slower (and burn battery), subsequent authentication is roughly as  
fast as CRAM-MD5, isn't it?

Given the figures Simon gave on the XMPP Security list, I think a  
recommended minimum of 4096 is reasonable. (I'm enclosing that  
message, because I think it's probably useful to supply some context).

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

[e-mail]
Content-Type: message/rfc822
Content-Disposition: inline
Content-Description: Re: [Security] TLS Libraries

Return-Path: <[e-mail]>
Received: from turner.dave.cridland.net (turner.dave.cridland.net [/var/run/lmtp])
	by turner.dave.cridland.net (Isode M-Box/14.4a0) with LMTP; Fri, 06 Mar 2009 15:50:18 +0000 (GMT)
Received: from turner.dave.cridland.net (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (smtp internal)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Fri, 6 Mar 2009 15:50:17 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 7A1D8498029
	for <[e-mail]>; Fri,  6 Mar 2009 15:50:17 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id n6bgOhviy5i4 for <[e-mail]>;
	Fri,  6 Mar 2009 15:50:11 +0000 (GMT)
Received: from mediauk.com (S76018.webhost1.cridland.net [83.138.143.221])
	by turner.dave.cridland.net (Postfix) with ESMTP id 4B8ED498012
	for <[e-mail]>; Fri,  6 Mar 2009 15:50:11 +0000 (GMT)
Received: from mail-qy0-f104.google.com (mail-qy0-f104.google.com [209.85.221.104])
	by mediauk.com (Postfix) with ESMTP id 4AE1473805A
	for <[e-mail]>; Fri,  6 Mar 2009 15:49:11 +0000 (GMT)
Received: by qyk2 with SMTP id 2sf207116qyk.23
        for <[e-mail]>; Fri, 06 Mar 2009 07:49:10 -0800 (PST)
Received: by 10.224.2.138 with SMTP id 10mr3829668qaj.299.1236354550727;
        Fri, 06 Mar 2009 07:49:10 -0800 (PST)
Received: by 10.224.2.138 with SMTP id 10mr3829663qaj.299.1236354550531;
        Fri, 06 Mar 2009 07:49:10 -0800 (PST)
Received: from atlas.jabber.org (atlas.jabber.org [208.68.163.215])
        by mx.google.com with ESMTP id 10si481135qyk.17.2009.03.06.07.49.10;
        Fri, 06 Mar 2009 07:49:10 -0800 (PST)
Received-SPF: pass (google.com: domain of [e-mail] designates 208.68.163.215 as permitted sender) client-ip=208.68.163.215;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [e-mail] designates 208.68.163.215 as permitted sender) smtp.mail=[e-mail]
Received: from [127.0.0.1] (atlas [127.0.0.1])
	by atlas.jabber.org (Postfix) with ESMTP id 8C44B21A6DA;
	Fri,  6 Mar 2009 10:21:53 -0600 (CST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39])
	by atlas.jabber.org (Postfix) with ESMTP id D298621A5F0
	for <[e-mail]>; Fri,  6 Mar 2009 10:21:51 -0600 (CST)
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127]
	helo=mocca.josefsson.org)
	by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
	(Exim 4.69) (envelope-from <[e-mail]>) id 1LfcIK-00047l-OJ
	for [e-mail]; Fri, 06 Mar 2009 16:49:05 +0100
From: Simon Josefsson <[e-mail]>
To: XMPP Security <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090306:[e-mail]::1rlS++zvZCokDHMW:2J/L
Date: Fri, 06 Mar 2009 16:49:04 +0100
In-Reply-To: <[e-mail]> (Dave
	Cridland's message of "Fri, 06 Mar 2009 15:26:12 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Security] TLS Libraries
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: XMPP Security <[e-mail]>
List-Id: XMPP Security <security.xmpp.org>
List-Unsubscribe: <http://mail.jabber.org/mailman/listinfo/security>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://mail.jabber.org/pipermail/security>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://mail.jabber.org/mailman/listinfo/security>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]

Dave Cridland <[e-mail]> writes:

> On Fri Mar  6 14:58:05 2009, Eric Rescorla wrote:
>> What do you mean rejects it? The attacker simulates a TCP-level
>> failure.
>> Alternately, he just stalls and waits for the client to give up if
>> he can't
>> brute-force the password in time.
>
> Right, well, I think I've made myself look stupid enough for one day,
> so I'll restrict myself to asking questions.
>
> So, we have some potential problems with the use of anything that's
> subject to an offline dictionary attack.
>
> Have you got any figures on timescales for this, and computing power
> required? I mean, is this something that anyone who hasn't upset the
> NSA or GCHQ should be concerned about, or are we within reasonable
> range of someone trying to phish credit card numbers?

SCRAM says to use an iteration count of 128, and due to the salting,
that means the attacker needs to perform 128 hashes to test a particular
password for one session.  'openssl speed sha1' on my machine does
around 1000000 16-byte hashes per second.  So the attacker can test
around 8000 passwords per second.  My /usr/share/dict/american-english
contains around 100000 words.  So it takes around 13 seconds to go
through this dictionary on my laptop.

This may not be completely correct, and I may be completely wrong about
something, but I hope the magnitude is about right.

Btw, this argues that the SCRAM iteration count should really be much
higher.  RFC 3962 uses 4096 by default but even that is slightly low.

/Simon

[e-mail]--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AAQMMd014598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 03:26:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AAQM40014597; Tue, 10 Mar 2009 03:26:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AAQL4p014588 for <[e-mail]>; Tue, 10 Mar 2009 03:26:22 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id A04E14AC64; Tue, 10 Mar 2009 11:26:20 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1236680780-87767-1/6/5 (2 recipients); Tue, 10 Mar 2009 11:26:20 +0100
Message-Id: <[e-mail]>
Date: Tue, 10 Mar 2009 11:24:54 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <Zz/Gxv9Zkapgqlmh+TtO/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> Is SCRAM likely to be ever used with client TLS authentication?

I was thinking about TLS session resumption, actually. Mobile clients 
have a way of losing the connection and then reconnecting, so TLS 
session resumption happens quite often.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AAMhmr014310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 03:22:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2AAMhMw014309; Tue, 10 Mar 2009 03:22:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2AAMfJ8014300 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Mar 2009 03:22:42 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1Lgz6d-00051V-40; Tue, 10 Mar 2009 11:22:40 +0100
From: Simon Josefsson <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]> <Zz/Gxv9Zkapgqlmh+TtO/[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090310:[e-mail]::CNniZWi/xYdun5x9:1AL+
X-Hashcash: 1:22:090310:[e-mail]::SQyfprVtG+eoQS+P:3zBD
Date: Tue, 10 Mar 2009 11:22:37 +0100
In-Reply-To: <Zz/Gxv9Zkapgqlmh+TtO/[e-mail]> (Arnt Gulbrandsen's message of "Tue, 10 Mar 2009 10:46:42 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen <[e-mail]> writes:

> Simon Josefsson writes:
>> Anyway, if we are deviating from the recommended minimum iteration
>> count of 1000 specified close to ten years ago I think we need a
>> motivation. Supporting mobile devices may be one, but I think we
>> need to understand whether there are mobile devices out there that
>> implement TLS, SCRAM, SMTP, IMAP etc without being able to do 1000
>> SHA-1 iterations quickly.
>
> They do it quickly, but it may just burn the battery.
>
> IMO we're better of with two values: A recommended default with vague
> language like "increase this by 15% per year", and a fixed minimum.
>
> I'd like the fixed minimum to be smallish (suitable for use when TLS
> has already told the server who's on the other end) and the
> recommended default to be much larger.

Is SCRAM likely to be ever used with client TLS authentication?  Why not
use EXTERNAL?

I believe the use case for SCRAM is for TLS without client
authentication, and possibly even without server authentication (hence
the channel binding).

/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 n2A9r4j0011642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 02:53:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2A9r4vk011641; Tue, 10 Mar 2009 02:53: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 n2A9qpc7011629 for <[e-mail]>; Tue, 10 Mar 2009 02:53:03 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.65.36] (92.40.65.36.sub.mbb.three.co.uk [92.40.65.36])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 10 Mar 2009 09:52:48 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Mar 2009 09:52:29 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Jeffrey Hutzelman <[e-mail]> writes:
>  
>
>>--On Monday, March 09, 2009 09:51:29 PM +0100 Simon Josefsson
>><[e-mail]> wrote:
>>    
>>
>>>There is a difference between a minimum value, and a default value.
>>>      
>>>
>>Yes, there is.  A minimum value is one which must be advertised to all
>>clients, including those which are mobile devices with limited
>>processing power.  If using SCRAM makes fetching mail from a phone too
>>slow, people will just keep using PLAIN.
>>    
>>
>Right.  This argues that the document need to discuss that point.
>
Agreed.

>I think a limited platform is a valid reason to not follow a SHOULD
>related to the iteration count.  However, right now it is the server
>that sets the iteration count.  Maybe we want the client to be able to
>request a particular iteration count?  On the other hand, this adds
>complexity to the protocol, and I'm not sure if it is worth it.
>  
>
I don't think the complexity is worth it.

Besides, the iteration count can be stored together with user's secret, 
so it is really controlled by the server end.

>Anyway, if we are deviating from the recommended minimum iteration count
>of 1000 specified close to ten years ago I think we need a motivation.
>Supporting mobile devices may be one, but I think we need to understand
>whether there are mobile devices out there that implement TLS, SCRAM,
>SMTP, IMAP etc without being able to do 1000 SHA-1 iterations quickly.
>  
>
Yes. Can anybody in the WG comment on this?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2A9mM8c011399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 02:48:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2A9mMWW011398; Tue, 10 Mar 2009 02:48:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2A9mAMr011376 for <[e-mail]>; Tue, 10 Mar 2009 02:48:21 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id D2CA14AC5B; Tue, 10 Mar 2009 10:48:09 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1236678489-87767-1/6/2 for [e-mail]; Tue, 10 Mar 2009 10:48:09 +0100
Message-Id: <Zz/Gxv9Zkapgqlmh+TtO/[e-mail]>
Date: Tue, 10 Mar 2009 10:46:42 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> Anyway, if we are deviating from the recommended minimum iteration 
> count of 1000 specified close to ten years ago I think we need a 
> motivation. Supporting mobile devices may be one, but I think we need 
> to understand whether there are mobile devices out there that 
> implement TLS, SCRAM, SMTP, IMAP etc without being able to do 1000 
> SHA-1 iterations quickly.

They do it quickly, but it may just burn the battery.

IMO we're better of with two values: A recommended default with vague 
language like "increase this by 15% per year", and a fixed minimum.

I'd like the fixed minimum to be smallish (suitable for use when TLS has 
already told the server who's on the other end) and the recommended 
default to be much larger.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2A8iQV7008319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 01:44:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2A8iQGn008318; Tue, 10 Mar 2009 01:44: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 n2A8iD5l008303 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 10 Mar 2009 01:44:25 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LgxZJ-00050n-Rp; Tue, 10 Mar 2009 09:44:11 +0100
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090310:[e-mail]::4ayGAXhMHypR476H:A3iS
X-Hashcash: 1:22:090310:[e-mail]::5mmATCr8qWgjJSgy:L1Dj
Date: Tue, 10 Mar 2009 09:44:08 +0100
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Mon, 09 Mar 2009 17:24:33 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Monday, March 09, 2009 09:51:29 PM +0100 Simon Josefsson
> <[e-mail]> wrote:
>
>> There is a difference between a minimum value, and a default value.
>
> Yes, there is.  A minimum value is one which must be advertised to all
> clients, including those which are mobile devices with limited
> processing power.  If using SCRAM makes fetching mail from a phone too
> slow, people will just keep using PLAIN.

Right.  This argues that the document need to discuss that point.  I
think a limited platform is a valid reason to not follow a SHOULD
related to the iteration count.  However, right now it is the server
that sets the iteration count.  Maybe we want the client to be able to
request a particular iteration count?  On the other hand, this adds
complexity to the protocol, and I'm not sure if it is worth it.

Anyway, if we are deviating from the recommended minimum iteration count
of 1000 specified close to ten years ago I think we need a motivation.
Supporting mobile devices may be one, but I think we need to understand
whether there are mobile devices out there that implement TLS, SCRAM,
SMTP, IMAP etc without being able to do 1000 SHA-1 iterations quickly.

/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 n29LOeO4082067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 14:24:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n29LOeiL082066; Mon, 9 Mar 2009 14:24:40 -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 n29LOcih082049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 9 Mar 2009 14:24:39 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-180-249.pools.spcsdns.net (72-61-128-224.pools.spcsdns.net [72.61.128.224]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n29LOXcG020075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 17:24:35 -0400 (EDT)
Date: Mon, 09 Mar 2009 17:24:33 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, March 09, 2009 09:51:29 PM +0100 Simon Josefsson 
<[e-mail]> wrote:

> There is a difference between a minimum value, and a default value.

Yes, there is.  A minimum value is one which must be advertised to all 
clients, including those which are mobile devices with limited processing 
power.  If using SCRAM makes fetching mail from a phone too slow, people 
will just keep using PLAIN.

-- 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 n29LKRRd081891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 14:20:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n29LKRcF081890; Mon, 9 Mar 2009 14:20:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29LKFsc081879 for <[e-mail]>; Mon, 9 Mar 2009 14:20:26 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.250.92] (92.40.250.92.sub.mbb.three.co.uk [92.40.250.92])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 9 Mar 2009 21:20:12 +0000
Message-ID: <[e-mail]>
Date: Mon, 09 Mar 2009 21:19:56 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: Re: SCRAM minimum PBKDF#2 iteration count
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>SCRAM currently contains:
>
>      Servers SHOULD announce a hash iteration-count of at least 128.
>
>I believe this is too low.  RFC 2898 (PKCS#5), an almost 10 year old
>document contains:
>
>   the difficulty of attack. For the methods in this document, a minimum
>   of 1000 iterations is recommended. This will increase the cost of
>
>A more recent document that uses PBKDF#2 is RFC 3962, published 2005,
>and it uses a default of 4096 iterations.
>
>There is a difference between a minimum value, and a default value.
>Still, I believe we could reasonable suggest a minimum value of 4096
>iterations for SCRAM.
>
>Thoughts?
>  
>
Works for me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29Kpq5x080419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 13:51:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n29KpqOe080418; Mon, 9 Mar 2009 13:51:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29KpcLT080406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 9 Mar 2009 13:51:51 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LgmRj-0003mS-Nk for [e-mail]; Mon, 09 Mar 2009 21:51:36 +0100
X-Hashcash: 1:22:090309:[e-mail]::35xarCUMb/X2b24j:flo7
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: SCRAM minimum PBKDF#2 iteration count
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 09 Mar 2009 21:51:29 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

SCRAM currently contains:

      Servers SHOULD announce a hash iteration-count of at least 128.

I believe this is too low.  RFC 2898 (PKCS#5), an almost 10 year old
document contains:

   the difficulty of attack. For the methods in this document, a minimum
   of 1000 iterations is recommended. This will increase the cost of

A more recent document that uses PBKDF#2 is RFC 3962, published 2005,
and it uses a default of 4096 iterations.

There is a difference between a minimum value, and a default value.
Still, I believe we could reasonable suggest a minimum value of 4096
iterations for SCRAM.

Thoughts?

/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 n29HPXfS068634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 10:25:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n29HPXi5068633; Mon, 9 Mar 2009 10:25:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n29HPL6L068615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 9 Mar 2009 10:25:32 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LgjE6-0003kk-Vd for [e-mail]; Mon, 09 Mar 2009 18:25:19 +0100
X-Hashcash: 1:22:090309:[e-mail]::uL8A4TQAJjExAnuE:7UYy
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: SCRAM as GSS-API mechanism
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 09 Mar 2009 18:25:16 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I have posted (although manually, so it may take up to 2 days until is
announced) draft-newman-auth-scram-gs2-01.txt.  Meanwhile, it is
available from:

http://josefsson.org/sasl-gs2/draft-newman-auth-scram-gs2-01.txt

It does not take into account the recent GS2 re-design proposals, but
merely attempts to frame the document as a 'SCRAM as GSS-API mechanism',
and refers to GS2 on how the protocol looks in SASL.

The document is thus lagging behind the discussion in the WG, but it
does contain some useful new material and different from scram-gs2-00
that we believed it worthwhile posting.

The point of this document is to allow us to chose a design path with
the ability to refer to real documents.  So we have at least two
choices:

1) draft-newman-auth-scram-10.txt
   SCRAM as native SASL mechanism

2) draft-newman-auth-scram-gs2-01.txt

   SCRAM as native GSS-API mechanism.  The mapping to SASL is defined
   through GS2.

I'll try to catch up on the GS2 discussions next.  I am sorry if some of
the points made here are obsolete or irrelevant in the light of more
recent discussions, but hopefully there is at least some useful points.

/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 n266dswH060695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 23:39:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n266dsAo060694; Thu, 5 Mar 2009 23:39:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n266dgsB060685 for <[e-mail]>; Thu, 5 Mar 2009 23:39:52 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n266dgeK017975 for <[e-mail]>; Fri, 6 Mar 2009 06:39:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n266dfwo047234 for <[e-mail]>; Thu, 5 Mar 2009 23:39:41 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n266FaMm017029; Fri, 6 Mar 2009 00:15:36 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n266FUuM017028; Fri, 6 Mar 2009 00:15:30 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 6 Mar 2009 00:15:30 -0600
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Chris Newman <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail], Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0FE4E16CFFB0F9824225E81D@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>

Ah, right.  The server must advertise only one or the other of the two
names, never both as it's the client's choice of mech name that will
tip off the server to any MITMs.

If the server says "I can do SCRAM with CB" and the client picks "SCRAM
w/o CB" but still does CB then nothing bad happens, but if the client
picks "SCRAM w/o CB" and does not do CB then authentication must fail.
Which is why there's no point to advertising both names.

So SCRAM-SHA-1-BETTER and SCRAM-SHA-1-LESSER will do as mech names, but
the client implementor needs to understand both names.

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 n264UMSh055874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 21:30:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n264UM9V055873; Thu, 5 Mar 2009 21:30:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n264UASc055866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 5 Mar 2009 21:30:21 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-180-249.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n264U44H001739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 23:30:06 -0500 (EST)
Date: Thu, 05 Mar 2009 23:30:04 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Chris Newman <[e-mail]>, Nicolas Williams <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
cc: [e-mail], Dave Cridland <[e-mail]>, [e-mail], [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <0FE4E16CFFB0F9824225E81D@446E7922C82D299DB29D899F>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0FE4E16CFFB0F9824225E81D@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, March 05, 2009 04:15:06 PM -0800 Chris Newman 
<[e-mail]> wrote:

> --On February 28, 2009 13:38:36 -0600 Nicolas Williams
> <[e-mail]> wrote:
>>  - We still have two mechanism names: the server advertises only one of
>>    them, indicating whether the server supports channel binding.
>
> Just so I'm clear, we would have:
>   SCRAM-SHA1-NOCB  (no channel bindings)
>   SCRAM-SHA1-CB    (mandatory channel bindings)
> And the server only advertises one of these two mechanisms.  I do not
> like this approach.
>
> I propose instead we do:
>   SCRAM-SHA1-OPTCB (channel bindings optional, includes flag indicating
> cb support)
>   SCRAM-SHA1-CB    (mandatory channel bindings, flag for cb support must
> be set)
> The server would advertise either the first or both mechanisms.
>
> The problem is that many implementers look at a single peer
> implementation and read the spec only as necessary to interoperate with
> that one peer. If, for example, a client of this type implements against
> a -NOCB server, then that client will fail to interoperate with a
> different -CB server. This in turn creates a deployment barrier for
> support of channel bindings since the -CB server can interoperate with
> that client if it advertises -NOCB but has to turn off -CB support to
> interoperate with clients that enforce the one-or-the-other-not-both rule
> at the same time.
>
> With the latter approach, we don't create a deployment barrier for the
> -CB mechanism, and the flag allows detection of the downgrade attack.
>
> The names I used above are for clarity of this example.  I'd actually
> prefer calling them "SCRAM-SHA1" and "SCRAM-SHA1-PLUS" (for -OPTCB and
> -CB respectively).  Mechanism names have a tendency to get into config
> files, error messages, logs and even set-up instructions.  The term
> "channel bindings" has little meaning for users/admins/etc and really
> shouldn't matter to them.  All they need to know is that the mechanism
> with mandatory channel bindings is "better".  Thus I suggest we use
> "-PLUS" to indicate "mandatory channel bindings".



I don't really care what you call them, but it's important to understand 
why there are two mechanism names.  Neither name means "mandatory channel 
bindings".  One name means the server has channel binding data, and the 
client can decide whether to use channel bindings.  The other name means 
the server does not have channel binding data, and the client must not use 
channel bindings.

Put another way, the mechanism name does not indicate whether the server 
wants to do channel bindings or whether it wants to require use of channel 
bindings; it indicates whether the server _can_ do channel bindings.  The 
goal is to negotiate the use of channel bindings whenever both sides are 
willing and able to use them, maintain interoperability when one or both 
sides are not willing or able to use CB, and prevent an attacker from 
forcing a downgrade.  This is accomplished by three steps:

1) server advertises whether it is able/willing to do CB
2) client decides whether to use CB, and tells server what it decided
3) client reports (1) back to server, protected by an HMAC.

The purpose of the second mechanism name is to accomplish (1).
The purpose of the second mechansim name is _not_ to indicate that use of 
CB is mandatory.  If you wanted to signal that, we'd actually need a 
_third_ mechanism name, because the client _must_ be able to distinguish 
the case where the server _cannot_ support channel bindings, in order to be 
able to do (2) correctly.

-- 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 n263Nxi2053973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 20:23:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n263NxgG053972; Thu, 5 Mar 2009 20:23:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n263NkoY053963 for <[e-mail]>; Thu, 5 Mar 2009 20:23:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.150] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <SbCXPgA0509=@rufus.isode.com>; Fri, 6 Mar 2009 03:23:44 +0000
Cc: Chris Newman <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail], Jeffrey Hutzelman <[e-mail]>, Dave Cridland <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Date: Thu, 5 Mar 2009 19:23:37 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0FE4E16CFFB0F9824225E81D@446E7922C82D299DB29D899F> <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mar 5, 2009, at 6:37 PM, Nicolas Williams wrote:

>
> On Thu, Mar 05, 2009 at 04:15:06PM -0800, Chris Newman wrote:
>> The names I used above are for clarity of this example.  I'd actually
>> prefer calling them "SCRAM-SHA1" and "SCRAM-SHA1-PLUS" (for -OPTCB  
>> and -CB
>> respectively).  Mechanism names have a tendency to get into config  
>> files,
>> error messages, logs and even set-up instructions.  The term "channel
>> bindings" has little meaning for users/admins/etc and really  
>> shouldn't
>> matter to them.  All they need to know is that the mechanism with  
>> mandatory
>> channel bindings is "better".  Thus I suggest we use "-PLUS" to  
>> indicate
>> "mandatory channel bindings".
>
> We might as well go for SCRAM-SHA1-LESSER and SCRAM-SHA1-BETTER :)
>
> I agree with these suggestions.  And I'm very glad you've made them,  
> as
> I was concerned that the two mech name thing might not be acceptable  
> to
> you.


I favor use of mechanism names to select features over negotiations  
within the 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 n2631wXN052953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 20:01:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n2631wXV052952; Thu, 5 Mar 2009 20:01: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-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n2631iDY052946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 20:01:55 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2631iq5026919 for <[e-mail]>; Fri, 6 Mar 2009 03:01:44 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 n2631itB010589 for <[e-mail]>; Thu, 5 Mar 2009 20:01:44 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n262bfC3016829; Thu, 5 Mar 2009 20:37:41 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n262bcpY016828; Thu, 5 Mar 2009 20:37:38 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 5 Mar 2009 20:37:38 -0600
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail], Jeffrey Hutzelman <[e-mail]>, Dave Cridland <[e-mail]>, [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0FE4E16CFFB0F9824225E81D@446E7922C82D299DB29D899F>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0FE4E16CFFB0F9824225E81D@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, Mar 05, 2009 at 04:15:06PM -0800, Chris Newman wrote:
> The names I used above are for clarity of this example.  I'd actually 
> prefer calling them "SCRAM-SHA1" and "SCRAM-SHA1-PLUS" (for -OPTCB and -CB 
> respectively).  Mechanism names have a tendency to get into config files, 
> error messages, logs and even set-up instructions.  The term "channel 
> bindings" has little meaning for users/admins/etc and really shouldn't 
> matter to them.  All they need to know is that the mechanism with mandatory 
> channel bindings is "better".  Thus I suggest we use "-PLUS" to indicate 
> "mandatory channel bindings".

We might as well go for SCRAM-SHA1-LESSER and SCRAM-SHA1-BETTER :)

I agree with these suggestions.  And I'm very glad you've made them, as
I was concerned that the two mech name thing might not be acceptable to
you.

I think we're very close then to a GS2 on which we can get consensus.
It adds a header consisting of a constant and a one-byte flag (really,
two bits) to the first client authentication message and to the channel
binding data, and it also adds the two mechanism name suffixes.

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 n260SOAr047188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 17:28:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n260SO52047187; Thu, 5 Mar 2009 17:28:24 -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 n260SDBG047177 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 17:28:23 -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 n260SDQO005955 for <[e-mail]>; Thu, 5 Mar 2009 16:28:13 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; format=flowed; charset=us-ascii
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <[e-mail]> for [e-mail]; Thu, 05 Mar 2009 16:28:13 -0800 (PST)
Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <[e-mail]>; Thu, 05 Mar 2009 16:28:12 -0800 (PST)
Date: Thu, 05 Mar 2009 16:15:06 -0800
From: Chris Newman <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-reply-to: <[e-mail]>
To: Nicolas Williams <[e-mail]>, Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail], Jeffrey Hutzelman <[e-mail]>, Dave Cridland <[e-mail]>, [e-mail]
Message-id: <0FE4E16CFFB0F9824225E81D@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On February 28, 2009 13:38:36 -0600 Nicolas Williams 
<[e-mail]> wrote:
>  - We still have two mechanism names: the server advertises only one of
>    them, indicating whether the server supports channel binding.

Just so I'm clear, we would have:
  SCRAM-SHA1-NOCB  (no channel bindings)
  SCRAM-SHA1-CB    (mandatory channel bindings)
And the server only advertises one of these two mechanisms.  I do not like 
this approach.

I propose instead we do:
  SCRAM-SHA1-OPTCB (channel bindings optional, includes flag indicating cb 
support)
  SCRAM-SHA1-CB    (mandatory channel bindings, flag for cb support must be 
set)
The server would advertise either the first or both mechanisms.

The problem is that many implementers look at a single peer implementation 
and read the spec only as necessary to interoperate with that one peer. 
If, for example, a client of this type implements against a -NOCB server, 
then that client will fail to interoperate with a different -CB server. 
This in turn creates a deployment barrier for support of channel bindings 
since the -CB server can interoperate with that client if it advertises 
-NOCB but has to turn off -CB support to interoperate with clients that 
enforce the one-or-the-other-not-both rule at the same time.

With the latter approach, we don't create a deployment barrier for the -CB 
mechanism, and the flag allows detection of the downgrade attack.

The names I used above are for clarity of this example.  I'd actually 
prefer calling them "SCRAM-SHA1" and "SCRAM-SHA1-PLUS" (for -OPTCB and -CB 
respectively).  Mechanism names have a tendency to get into config files, 
error messages, logs and even set-up instructions.  The term "channel 
bindings" has little meaning for users/admins/etc and really shouldn't 
matter to them.  All they need to know is that the mechanism with mandatory 
channel bindings is "better".  Thus I suggest we use "-PLUS" to indicate 
"mandatory channel bindings".

		- 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 n25NE0p7044640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 16: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 n25NE0jZ044639; Thu, 5 Mar 2009 16: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 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 n25NDkHt044604 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Thu, 5 Mar 2009 16:13:56 -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 n25NDj1W027059 for <[e-mail]>; Thu, 5 Mar 2009 15:13:45 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; format=flowed; charset=us-ascii
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <[e-mail]> for [e-mail]; Thu, 05 Mar 2009 15:13:45 -0800 (PST)
Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <[e-mail]>; Thu, 05 Mar 2009 15:13:39 -0800 (PST)
Date: Thu, 05 Mar 2009 15:13:36 -0800
From: Chris Newman <[e-mail]>
Subject: Aside - security layers and identity (was Re: New GS2 design ... )
In-reply-to: <18794.1235904480.961002@invsysm1>
To: Dave Cridland <[e-mail]>, Nicolas Williams <[e-mail]>
Cc: [e-mail], [e-mail], Arnt Gulbrandsen <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
Message-id: <84E1B814FD1345A3B1236874@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <15219.1235820001.492969@invsysm1> <[e-mail]> <18794.1235904480.961002@invsysm1>
Sender: [e-mail]
Precedence: 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 March 1, 2009 10:48:00 +0000 Dave Cridland <[e-mail]> wrote:
> If I ruled the world, then - after mandating more important things like
> food for all, world peace, and British spelling - I'd recast TLS itself
> as a security layer extension within SASL, and/or extend SCRAM with
> optional security layers.

I actually disagree with you on this one point based on my experience as a 
production server engineer.

Certain software components accumulate certain types of complexity the 
longer they are deployed in production.  To keep software maintainable, 
it's important to avoid designs that force different classes of complexity 
to mix together into a monolithic system.

There is a class of complexity related to user identity services on 
servers.  This includes identity lookup, caching, password policy, 
single-sign-on-capabilities, server affinity, extensible attributes, 
identity plug-ins, proxy support, generation of SAML-like assertions, etc.

There is a class of complexity related to security layers and PKIX (TLS). 
This requires a stack-able I/O subsystem, tie-ins to crypto hardware (for 
both security layers and PKIX -- and it's unfortunate these are linked), 
PKIX parsing, cert chain verification, sync/async I/O issues, etc.  The 
production SSL library I'm most familiar with (NSS, used by Firefox and 
several Sun/Netscape/RedHat servers) has 6 full time engineers working on 
it last time I checked and they're swamped with work.

Both of these subsystems become huge and complex in production server 
software, and the complexity profiles are almost completely disjoint.  I 
want the tie-ins between these complexity profiles to be as minimal as 
possible.  Specifically there are only three places where data must be 
shared between the identity subsystem and the TLS subsystem:

1. Whether or not TLS security layer is active
2. TLS Client certificate (for Subject/SubjectAltName mapping and lookup to 
identity system) and PKIX verification status thereof.
3. Channel bindings

This is a rather clean abstraction.  I don't want my complex TLS stack 
contaminated by identity services, and I don't want my complex identity 
stack contaminated by security layer or PKIX services.  Keeping them 
separate is better software architecture, IMHO, at least on the server side.

		- 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 n23J5hWq065616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 12:05:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n23J5hEA065615; Tue, 3 Mar 2009 12:05:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-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 n23J5W5g065603 for <[e-mail]>; Tue, 3 Mar 2009 12:05:42 -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 n23J5V0p022135 for <[e-mail]>; Tue, 3 Mar 2009 19:05:32 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n23J5Vea015417 for <[e-mail]>; Tue, 3 Mar 2009 12:05:31 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n23IuU0k014467 for <[e-mail]>; Tue, 3 Mar 2009 12:56:30 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n23IuU7u014466 for [e-mail]; Tue, 3 Mar 2009 12:56:30 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 3 Mar 2009 12:56:30 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: Thanks
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Earlier in February I complained about the lack of feedback that GS2
proponents were receiving from the "pure SASL" community.  I'd like to
thank you all for the all the feedback we've received since, on- and
off-list.  I appreciate it greatly, and it has helped us make much
progress.  No doubt there were better ways to elicit such feedback than
to complain about the lack of it, but I was too frustrated to see it;
sorry, and thanks.

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 n23IvwZt064915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 11:57:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n23Ivw3e064914; Tue, 3 Mar 2009 11:57:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n23Ivkc4064904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 3 Mar 2009 11:57:57 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-236-105.pools.spcsdns.net (173-115-63-122.pools.spcsdns.net [173.115.63.122]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n23IvaX9014086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 13:57:38 -0500 (EST)
Date: Tue, 03 Mar 2009 13:57:36 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, March 03, 2009 03:39:09 PM +0100 Simon Josefsson 
<[e-mail]> wrote:

> X. Mechanism Name
>
>    The SASL mechanism name for a GSS-API mechanism is learned from an
>    IANA registry (a "friendly name"), or it can be derived from the OID
>    algorithmically (an "OID-derived name").  To avoid interoperability
>    problems when GSS-API mechanisms are deployed in SASL using a
>    OID-derived name (when a friendly name has not been registered yet) a
>    server SHOULD advertise both the friendly name and the OID-derived
>    name.  The wire protocols MUST be identical regardless of which of
>    the two names a client uses.

Don't do this.  The idea is that the SASL-like mechanism name is a property 
of the mechanism which must be specified when the mechanism is defined, 
just like the OID.  They cannot be added later(*); if a mechanism is 
defined without a name, then its name is derived from its OID.

Mechanism names like this should be limited to 16 characters and upper 
case.  This allows them to fit within SASL's name constraints while still 
allowing for a prefix like "GS2-".



(*) Except that when we first create the mechanism-name property, we can 
define its value for GSS-API mechanisms that already exist.  Names assigned 
in this way are treated the same as if they'd been assigned when the 
mechanism was defined; in particular, such mechanisms are _never_ named by 
OID.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n23HBse7059046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 10:11:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n23HBspU059045; Tue, 3 Mar 2009 10:11:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n23HBgdu059029 for <[e-mail]>; Tue, 3 Mar 2009 10:11:53 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n23HBgEi012277 for <[e-mail]>; Tue, 3 Mar 2009 17:11:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n23HBgt6061205 for <[e-mail]>; Tue, 3 Mar 2009 10:11:42 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n23Gt83G014254; Tue, 3 Mar 2009 10:55:09 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n23Gt3t0014253; Tue, 3 Mar 2009 10:55:03 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 3 Mar 2009 10:55:03 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Mar 03, 2009 at 03:39:09PM +0100, Simon Josefsson wrote:
> I am slowly reading through this thread, but I just want to say that I
> think the above sounds like a good compromise.  Getting good SASL
> mechanism names for GSS-API mechanisms is important.

Good.

> I started writing a document to specify the GSS_SASL_name function, but
> the document became rather GS2 specific.  It doesn't seem like anything
> other than GS2 will use it?  If so, isn't it sufficient to add a section
> to GS2 which says something like the text below?  [...]

Correct.  Yes.

> Alternatively, we make the GSS-API interface less tied to SASL, and call
> it, e.g., GSS_Mech_Human_Name.  It can still use the same syntax as SASL
> mech names, so it would still work for GS2.  This function would be
> useful by GSS-API programs for other purposes, e.g., to allow
> administrators to configure GSS-API mechanism using friendly names
> rather than by OIDs.

It definitely needs to be tied to SASL, though it doesn't have to have
SASL in the function name.

Solaris has pretty names for GSS-API mechs, but a very non-standard
interface for using them (rpc_gss_mech_to_oid() -- not even
gss_-prefixed and not in libgss).

Thus I think that the two (SASL and human-friendly names) must be
separate, though they MAY be identical, at least in some locales.  Might
as well add a mechanism description too.

x.  GSS_Mechanism_name()

   Inputs:

   o desired_mech OBJECT IDENTIFIER

   Outputs:

   o mech_name UTF-8 STRING -- name of this mechanism, possibly
     localized

   o sasl_mech_name OCTET STRING -- SASL name for this mechanism
     (really, ASCII)

   o mech_description UTF-8 STRING -- possibly localized description of
     this mechanism.

x.1  C-bindings

   OM_uint32 gss_mechanism_name(
     OM_uint32    *minor_status,
     gss_buffer_t mech_name,
     gss_buffer_t sasl_mech_name,
     gss_buffer_t mech_description,
   );

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 n23EdV80048944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 07:39:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n23EdVeu048943; Tue, 3 Mar 2009 07:39:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n23EdHwa048907 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 3 Mar 2009 07:39:29 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LeVm3-0008Tq-9X; Tue, 03 Mar 2009 15:39:12 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090303:[e-mail]::AVdTVpocONXI8VZG:1o76
X-Hashcash: 1:22:090303:[e-mail]::A+MxZPVb7koMu5/s:8QAf
X-Hashcash: 1:22:090303:[e-mail]::bNe7ZlTVmxMNFsg8:LAcm
X-Hashcash: 1:22:090303:[e-mail]::8/QtER2ZHP9omgnr:RlTR
Date: Tue, 03 Mar 2009 15:39:09 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 23 Feb 2009 16:02:52 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> Here's what we'll do about GS2 mech names:
>
> 1) Create a registry of GSS-API mechanism OID -> pretty SASL mech name
>    mappings.
>
> 2) Add an abstract API to the GSS-API: GSS_SASL_name() that outputs the
>    SASL name of a GSS-API mechanism.
>
> 3) GS2 will use the pretty name on wire for all GSS-API mechanisms
>    except for mechanisms that have no registered SASL name.
>
>    For mechanisms that have no registered SASL name GS2 will use a
>    hash-based name.  This means it's important for GSS-API mechanisms to
>    be born with a SASL name.
>
>    (Also, what we call "composed mechanisms" may not have pretty SASL
>    names ever, but that's really not an issue as no such mechanisms
>    exist now and anyways they are mechanically composed, thus they
>    arguably don't need pretty names or, in any case, might end up having
>    very long composed pretty names.)
>
> I think that should settle the last major issue.

I am slowly reading through this thread, but I just want to say that I
think the above sounds like a good compromise.  Getting good SASL
mechanism names for GSS-API mechanisms is important.

I started writing a document to specify the GSS_SASL_name function, but
the document became rather GS2 specific.  It doesn't seem like anything
other than GS2 will use it?  If so, isn't it sufficient to add a section
to GS2 which says something like the text below?  This also attempts to
address the interop problem when GSS-API mechanisms are deployed within
SASL and the SASL name is registered with IANA only later on.

Alternatively, we make the GSS-API interface less tied to SASL, and call
it, e.g., GSS_Mech_Human_Name.  It can still use the same syntax as SASL
mech names, so it would still work for GS2.  This function would be
useful by GSS-API programs for other purposes, e.g., to allow
administrators to configure GSS-API mechanism using friendly names
rather than by OIDs.

Thoughts?

X. Mechanism Name

   The SASL mechanism name for a GSS-API mechanism is learned from an
   IANA registry (a "friendly name"), or it can be derived from the OID
   algorithmically (an "OID-derived name").  To avoid interoperability
   problems when GSS-API mechanisms are deployed in SASL using a
   OID-derived name (when a friendly name has not been registered yet) a
   server SHOULD advertise both the friendly name and the OID-derived
   name.  The wire protocols MUST be identical regardless of which of
   the two names a client uses.

Y. IANA Considerations

   The IANA will create a registry that maps GSS-API OIDs to SASL
   mechanism names.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n239xEjW027669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 02:59:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n239xEl2027668; Tue, 3 Mar 2009 02:59:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n239xDlt027661 for <[e-mail]>; Tue, 3 Mar 2009 02:59:13 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.199.136] (92.40.199.136.sub.mbb.three.co.uk [92.40.199.136])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <Saz=[e-mail]>; Tue, 3 Mar 2009 09:59:10 +0000
Message-ID: <[e-mail]>
Date: Tue, 03 Mar 2009 09:58:54 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <[e-mail]>
CC: [e-mail]
Subject: Re: A SASL/GSS-API bridge in the *other* direction?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Mon, Mar 02, 2009 at 09:50:09AM +0000, Alexey Melnikov wrote:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>Any SASL mechanism that uses cryptographic keys and has nonces could be
>>>adapted to provide a "SASL PRF" [without changes to SASL apps] and so
>>>any such mechanism could be used to build a GSS-API mechanism.    
>>>
>>Right. I was thinking about doing something like this in relationship to 
>>TLS.
>>    
>>
>Could you expand?  Did you mean using TLS as a SASL mechanism?  Or SASL
>in TLS?  The latter is going to run into the same problems that TLS-GSS
>did; we did discuss that in a jabber room or three at one or more IETF
>meetings.
>
I was thinking about defining a bridge from SASL to TLS, so that SASL 
mechanisms can be used as authentication components in TLS.
So at the end of a successful SASL authentication a shared key would be 
created that can be used by TLS encryption.
For example SRP in TLS (I know it is a solved problem, but you should 
see what I wanted to do).

However I've realized that TLS negotiation typically happends before 
SASL, so that wouldn't work for many apps protocols.

>>>And any SASL mechanism that can provide a SASL PRF can be used to provide 
>>>both
>>>GSS-API channel binding and GSS-API per-message tokens.
>>>
>>>
>>>Is there any reason that a "SASL PRF" couldn't be constructed for
>>>DIGEST-MD5, SCRAM, even CRAM-MD5?  I can't see one.
>>>      
>>>
>>I can't think of any either.
>>    
>>
>OK.
>
>Do you think that a SASL equivalent to RFC4401, and a DIGEST-MD5 and
>SCRAM equivalent to RFC4402 is simple enough?
>  
>
I think that might be easy enough. I don't think there is a need to 
define RFC 4402 equivalent for every available SASL mechanism, but 
defining it for SCRAM and possible DIGEST-MD5 shouldn't be difficult.

>In order to keep round-trip counts down it's important to be able to
>have equivalen support for GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL
>prf_key values in the SASL PRF.  For password-based mechanisms that's
>trivially done.  
>
>>>Are there any other reasons why such a bridge would not be a good idea?
>>>      
>>>
>>No, go for it :-).
>>    
>>
>>>Principal naming issues, perhaps?
>>>      
>>>
>>Can you elaborate?
>>
>Well, I was reaching -- wondering if there might be anything in SASL
>mechanisms' principal naming that might be fatal for such a bridge, but
>I can't think of anything.  E.g., DIGEST-MD5's notion of realm, or the
>fact that SCRAM doesn't have one, but neither is a problem w.r.t.
>GSS-API principal naming.  
>
I don't think that this is going to be a problem for existing SASL 
mechanisms.
However, principal naming is SASL-mechanism-specific, so this statement 
is not going to be true in general.

>>>If such a bridge is doable we could just adopt Chris' pure SASL SCRAM
>>>without further ado.    
>>>
>I await additional comments, but I'm reasonably sure that such a bridge
>is quite doable.  Mechanism naming could be done mechanically by
>encoding each SASL mechanism's name as OIDs :)  For example:
>
> - "SCRAM"'s bridged OID might become (yes, I'm being real cute here,
>   encoding every pair of letters as an OID label, though one needn't
>   stop at two):
>
>   {1(iso), 3(org), 6(dod), 1(internet), 5(security),
>       21313(gss-bridged-sa), 21315(sc), 21057(ra), 77(m)}
>  
>
:-)
Who owns 1(iso), 3(org), 6(dod), 1(internet), 5(security)?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n238lDap023052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 01:47:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n238lD3I023051; Tue, 3 Mar 2009 01:47: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 n238l1cK023041 for <[e-mail]>; Tue, 3 Mar 2009 01:47:12 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.199.136] (92.40.199.136.sub.mbb.three.co.uk [92.40.199.136])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 3 Mar 2009 08:46:59 +0000
Message-ID: <[e-mail]>
Date: Tue, 03 Mar 2009 08:46:47 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: A SASL/GSS-API bridge in the *other* direction?
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Mon, Mar 02, 2009 at 07:18:32PM -0500, Jeffrey Hutzelman wrote:
>  
>
>>I suppose one could define a PRF separately for each new SASL mechanism, 
>>but then a bridge doesn't really gain you much.  You don't save the effort 
>>of specifying each mechanism separately for GSS, or of implementing, or of 
>>testing, and you don't give the users the ability to drop a new SASL 
>>mechanism into the existing framework and immediately start using it with 
>>GSS-API apps.
>>
I think It would be easier to define such bridge for each SASL mechanism 
that defines a security layer. (How ironic)
I certainly see no point in using CRAM-MD5 in GSS.

>>GS2 actually buys us all of these things, by building SASL 
>>mechanisms on top of features that every GSS-API mechanism (or at least, 
>>every useful one) already has, and that every new GSS-API mechanism will 
>>have.
>>    
>>
>Thank you.  This is a key point.
>  
>
>>I'm not even sure it is a good idea to do this instead of GS2 for the 
>>specific case of SCRAM.  We already basically have a SCRAM mechanism in the 
>>form of draft-newman-auth-scram.  We have reduced the bits added by GS2 to 
>>a pair of flags in the first message, one of which is constant, and the 
>>same two flags plus the mechanism name prefixed to the channel binding 
>>data.  I think that is quite simple enough for anyone.
>>    
>>
>I wasn't sure that the two mechanism names part would be simple enough
>-- noone had spoken to that.
>  
>
I think we need more feedback on the final proposal before deciding.

>>So, the benefit of recasting SCRAM in terms of a "reverse" bridge seems to 
>>be relatively low.  Now, let's look at the cost...
>>
>>- It becomes necessary to define the PRF, not only for SCRAM but for
>> every new SASL mechanism.
>>- It becomes necessary to implement and test the PRF, not only for SCRAM
>> but for every new SASL mechanism.  Possibly single-app implementations
>> can get away with this, but nothing resembling a library can.
>>    
>>
I think my suggestion above addresses that.

>>- With bridges in both directions, we have to define complicated rules
>> to prevent them from being composed.
>>    
>>
That is true.

>>- The reverse bridge document will never be completed, because no one
>> has time to write it (I don't, Alexey doesn't, Nico doesn't).
>>    
>>
>Thanks.  I agree.
>  
>
Well, my time is running out either way. If I don't finish SCRAM during 
SF, then I might not have time to finish 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 n230e1fq003807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 17:40:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n230e0oe003806; Mon, 2 Mar 2009 17:40:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 n230dnvS003773 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 2 Mar 2009 17:40:00 -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 n230dn7D002628 for <[e-mail]>; Tue, 3 Mar 2009 00:39:49 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 n230dmh1009144 for <[e-mail]>; Mon, 2 Mar 2009 17:39:48 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n230NI0e013432; Mon, 2 Mar 2009 18:23:18 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n230NHUg013431; Mon, 2 Mar 2009 18:23:17 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 2 Mar 2009 18:23:17 -0600
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail]
Subject: Re: A SASL/GSS-API bridge in the *other* direction?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 02, 2009 at 07:18:32PM -0500, Jeffrey Hutzelman wrote:
> I suppose one could define a PRF separately for each new SASL mechanism, 
> but then a bridge doesn't really gain you much.  You don't save the effort 
> of specifying each mechanism separately for GSS, or of implementing, or of 
> testing, and you don't give the users the ability to drop a new SASL 
> mechanism into the existing framework and immediately start using it with 
> GSS-API apps.  GS2 actually buys us all of these things, by building SASL 
> mechanisms on top of features that every GSS-API mechanism (or at least, 
> every useful one) already has, and that every new GSS-API mechanism will 
> have.

Thank you.  This is a key point.

> I'm not even sure it is a good idea to do this instead of GS2 for the 
> specific case of SCRAM.  We already basically have a SCRAM mechanism in the 
> form of draft-newman-auth-scram.  We have reduced the bits added by GS2 to 
> a pair of flags in the first message, one of which is constant, and the 
> same two flags plus the mechanism name prefixed to the channel binding 
> data.  I think that is quite simple enough for anyone.

I wasn't sure that the two mechanism names part would be simple enough
-- noone had spoken to that.

> So, the benefit of recasting SCRAM in terms of a "reverse" bridge seems to 
> be relatively low.  Now, let's look at the cost...
> 
> - It becomes necessary to define the PRF, not only for SCRAM but for
>  every new SASL mechanism.
> - It becomes necessary to implement and test the PRF, not only for SCRAM
>  but for every new SASL mechanism.  Possibly single-app implementations
>  can get away with this, but nothing resembling a library can.
> - With bridges in both directions, we have to define complicated rules
>  to prevent them from being composed.
> - The reverse bridge document will never be completed, because no one
>  has time to write it (I don't, Alexey doesn't, Nico doesn't).

Thanks.  I agree.

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 n230IkaD002937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 17:18:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n230IkF6002936; Mon, 2 Mar 2009 17:18:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n230IZcU002912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 2 Mar 2009 17:18:46 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n230IWJN019717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 19:18:32 -0500 (EST)
Date: Mon, 02 Mar 2009 19:18:32 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: A SASL/GSS-API bridge in the *other* direction?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, March 02, 2009 12:45:08 AM -0600 Nicolas Williams 
<[e-mail]> wrote:

> It seems to me that we could pursue a SASL/GSS-API bridge in the
> opposite direction of GS2, either in addition to or instead of GS2.

I don't think this is viable _instead of_ GS2; there are existing GSS-API 
mechanisms, Kerberos included, which we need to have available as SASL 
mechanisms.

I'm not sure it is viable _in addition to_ GS2, because it imposes a fairly 
signficiant new requirement on SASL mechanisms, namely that they provide a 
PRF.  Currently SASL mechanisms do not provide a PRF, no SASL applications 
use this feature, and I would not expect any new SASL applications to use 
this feature.  That means you're proposing that all new SASL mechanisms 
provide a feature which will likely not be tested or used during the 
development of the mechanism.

I suppose one could define a PRF separately for each new SASL mechanism, 
but then a bridge doesn't really gain you much.  You don't save the effort 
of specifying each mechanism separately for GSS, or of implementing, or of 
testing, and you don't give the users the ability to drop a new SASL 
mechanism into the existing framework and immediately start using it with 
GSS-API apps.  GS2 actually buys us all of these things, by building SASL 
mechanisms on top of features that every GSS-API mechanism (or at least, 
every useful one) already has, and that every new GSS-API mechanism will 
have.


I'm not even sure it is a good idea to do this instead of GS2 for the 
specific case of SCRAM.  We already basically have a SCRAM mechanism in the 
form of draft-newman-auth-scram.  We have reduced the bits added by GS2 to 
a pair of flags in the first message, one of which is constant, and the 
same two flags plus the mechanism name prefixed to the channel binding 
data.  I think that is quite simple enough for anyone.

Making SCRAM really usable as a GSS-API mechanism requires that we define a 
PRF, MIC tokens, and Wrap tokens.  These features are not used by GS2 and 
will never be used by SASL, so they can actually be defined in a separate 
document that need not even be read by SASL implementors.  A flag would 
likely be required to indicate that these features are supported, but the 
existing SCRAM message format already provides a suitable place for such a 
flag, in the form of an extension.

So, the benefit of recasting SCRAM in terms of a "reverse" bridge seems to 
be relatively low.  Now, let's look at the cost...

- It becomes necessary to define the PRF, not only for SCRAM but for
  every new SASL mechanism.
- It becomes necessary to implement and test the PRF, not only for SCRAM
  but for every new SASL mechanism.  Possibly single-app implementations
  can get away with this, but nothing resembling a library can.
- With bridges in both directions, we have to define complicated rules
  to prevent them from being composed.
- The reverse bridge document will never be completed, because no one
  has time to write it (I don't, Alexey doesn't, Nico doesn't).


Oh, and doing this would _not_ allow us to just adopt Chris's document 
as-is, because we'd still have to deal with the issue of supporting channel 
bindings, allowing them to be ignored if one or both sides can't support 
them, but detecting when both sides _can_ support them but a MITM attempts 
to prevent their use.  I think we've decided that's important, and it has 
to be solved even if we make SCRAM a pure SASL mechanism.  Of course, the 
solution wouldn't look much different from what we've devised for GS2, 
which in turn is very nearly the only thing GS2 adds to SCRAM's messages.

-- 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 n22NWQY4001303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 16:32:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22NWP1G001302; Mon, 2 Mar 2009 16:32:25 -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 n22NWDPr001293 for <[e-mail]>; Mon, 2 Mar 2009 16:32:25 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.187] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SaxseAA050g=@rufus.isode.com>; Mon, 2 Mar 2009 23:32:11 +0000
Message-ID: <[e-mail]>
Date: Mon, 02 Mar 2009 23:31:52 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Love H=F6rnquist =C5strand wrote:

> 22 feb 2009 kl. 02:47 skrev Alexey Melnikov:
>
>> This contains some minor fixes discovered by Dave Cridland and myself
>> while implementing the spec (actually 2 separate implementations, =20
>> one in
>> C and one in Python), in particular an error in ABNF production name.
>
> No test vectors, specificly for the string2key function (which =20
> probably not is going to change).

Ok, I can add that once we have 2 independent 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 n22NPjao001072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 16:25:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22NPiWL001071; Mon, 2 Mar 2009 16:25:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22NPYXd001063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 2 Mar 2009 16:25:44 -0700 (MST) (envelope-from [e-mail])
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id ED9A354AE430 for <[e-mail]>; Mon,  2 Mar 2009 15:25:06 -0800 (PST)
Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Brightmail Gateway) with ESMTP id 9A40828085 for <[e-mail]>; Mon,  2 Mar 2009 15:25:05 -0800 (PST)
X-AuditID: 11807134-a5855bb000000ff0-29-49ac6ad1bdc7
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with ESMTP id 00F8B2808B for <[e-mail]>; Mon,  2 Mar 2009 15:25:05 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; delsp=yes; charset=iso-8859-1; format=flowed
Received: from [17.202.106.22] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 02 Mar 2009 15:25:04 -0800 (PST)
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
Content-transfer-encoding: quoted-printable
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Message-id: <[e-mail]>
In-reply-to: <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Date: Mon, 02 Mar 2009 15:25:04 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
X-Mailer: Apple Mail (2.1047)
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

2 mar 2009 kl. 14:55 skrev Hallvard B Furuseth:

> Love H=F6rnquist =C5strand writes:
>>>> Why is ClientProof  the result of ClientKey XOR ClientSignature ?
>>>> That  does that accomplish ?
>>>
>>> The server is able to calculate ClientSignature. =46rom the =20
>>> ClientProof
>>> and that it can recover ClientKey, apply hash function once to get
>>> StoredKey and can verify that the client really knows the StoredKey
>>> (i.e. it knows the password).
>>
>> What accomplishes that that HMAC(stored-key, auth-message) doesn't
>> already.
>
> If clients could send that to authenticate, stored-key would be
> password-equivalent.  That is, someone with access to stored-key could
> impersonate the user.  Sending ClientKey XOR ClientSignature makes =20
> that
> one step harder:  You need both stored-key and to have listened to an
> auth session.

Thank you for explain this, this need to go into the draft.

Love




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22Mu9Vm099466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 15:56:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22Mu9tw099465; Mon, 2 Mar 2009 15:56:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-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 n22MttbL099448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 2 Mar 2009 15:56:07 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LeH3C-0006sW-07; Mon, 02 Mar 2009 23:55:54 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LeH3B-0004NX-Mh; Mon, 02 Mar 2009 23:55:53 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LeH3B-000535-EG; Mon, 02 Mar 2009 23:55:53 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Message-ID: <[e-mail]>
Date: Mon, 2 Mar 2009 23:55:53 +0100
To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: E82C4C962D3F86C604EE4DEC941E8E4A36173832
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 1407 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>

Love H=F6rnquist =C5strand writes:
>>> Why is ClientProof  the result of ClientKey XOR ClientSignature =3F=

>>> That  does that accomplish =3F
>>
>> The server is able to calculate ClientSignature. From the ClientProo=
f
>> and that it can recover ClientKey, apply hash function once to get
>> StoredKey and can verify that the client really knows the StoredKey
>> (i.e. it knows the password).
>=20
> What accomplishes that that HMAC(stored-key, auth-message) doesn't =20=

> already.

If clients could send that to authenticate, stored-key would be
password-equivalent.  That is, someone with access to stored-key could
impersonate the user.  Sending ClientKey XOR ClientSignature makes that=

one step harder:  You need both stored-key and to have listened to an
auth session.

--=20
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 n22Ic3ZC084630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 11:38:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22Ic3fC084629; Mon, 2 Mar 2009 11:38:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22Ic17c084623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 2 Mar 2009 11:38:02 -0700 (MST) (envelope-from [e-mail])
Received: from relay10.apple.com (relay10.apple.com [17.128.113.47]) by mail-out4.apple.com (Postfix) with ESMTP id 664915733B40 for <[e-mail]>; Mon,  2 Mar 2009 10:37:34 -0800 (PST)
Received: from relay10.apple.com (unknown [127.0.0.1]) by relay10.apple.com (Symantec Brightmail Gateway) with ESMTP id 47C6128055 for <[e-mail]>; Mon,  2 Mar 2009 10:37:34 -0800 (PST)
X-AuditID: 1180712f-ad974bb0000012d3-64-49ac276e8728
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay10.apple.com (Apple SCV relay) with ESMTP id 264D728050 for <[e-mail]>; Mon,  2 Mar 2009 10:37:34 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; delsp=yes; charset=iso-8859-1; format=flowed
Received: from [17.202.106.22] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 02 Mar 2009 10:37:34 -0800 (PST)
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
Content-transfer-encoding: quoted-printable
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Message-id: <[e-mail]>
In-reply-to: <[e-mail]>
Cc: SASL WG <[e-mail]>, [e-mail]
Date: Mon, 02 Mar 2009 10:37:33 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.1047)
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ping ?

23 feb 2009 kl. 08:59 skrev Love H=F6rnquist =C5strand:

>>>>    This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF  =20=

>>>> and
>>>>    with dkLen =3D=3D output length of HMAC() =3D=3D output length =
of H().
>>>
>>> If it is PBKDF2 is should say so and not be fuzzy.
>>
>> If somebody can verify that independently, then I will change the =20
>> text ;-).
>
> Just write that it uses PBKDF2 with HMAC and output keysize =3D sizeof=20=

> (H(), put the description in an non normative appendix.
>
> It looks like PBKDF2 to me.
>
>>> When I see Hi(str, salt), I get confused every time, i is an input
>>> parameter, but is still part of the function name ?
>>
>> Yea. It Should be <Something>(str, salt, i)
>>
>>> Why is ClientProof  the result of ClientKey XOR ClientSignature ?
>>> That  does that accomplish ?
>>
>> The server is able to calculate ClientSignature. =46rom the =
ClientProof
>> and that it can recover ClientKey, apply hash function once to get
>> StoredKey and can verify that the client really knows the StoredKey
>> (i.e. it knows the password).
>
> If the client can calculate ClientSignature =3D HMAC(H(H(PBKDF2=20
> (password, salt, i))), AuthMessage),
> I would not be worried about it not knowing the password, why do you =20=

> need the extra step ?
>
> Chris, this was in -00 of the draft, why did you do it this way ?
>
> Right now the client and server key differences is:
>
> ClientKey =3D H(SaltedPassword)
> ServerKey =3D HMAC(SaltedPassword, salt)
>
> Why are the derived by two different methods ? (why not XKey =3D HMAC=20=

> (SaltedKey, "X key")
>
> Love
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22IbNEC084595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 11:37:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22IbNfN084594; Mon, 2 Mar 2009 11:37:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22IbCDY084538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 2 Mar 2009 11:37:22 -0700 (MST) (envelope-from [e-mail])
Received: from relay10.apple.com (relay10.apple.com [17.128.113.47]) by mail-out3.apple.com (Postfix) with ESMTP id ED1D354A4BF1 for <[e-mail]>; Mon,  2 Mar 2009 10:37:11 -0800 (PST)
Received: from relay10.apple.com (unknown [127.0.0.1]) by relay10.apple.com (Symantec Brightmail Gateway) with ESMTP id D92BE28055 for <[e-mail]>; Mon,  2 Mar 2009 10:37:11 -0800 (PST)
X-AuditID: 1180712f-ad173bb0000012d3-1e-49ac2757a718
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay10.apple.com (Apple SCV relay) with ESMTP id BD9C228054 for <[e-mail]>; Mon,  2 Mar 2009 10:37:11 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_InNdRefGUqGpRtyQqY4FwQ)"
Received: from [17.202.106.22] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 02 Mar 2009 10:37:11 -0800 (PST)
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Message-id: <[e-mail]>
In-reply-to: <[e-mail]>
Cc: SASL WG <[e-mail]>
Date: Mon, 02 Mar 2009 10:37:11 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.1047)
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary_(ID_InNdRefGUqGpRtyQqY4FwQ)
Content-type: text/plain; delsp=yes; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

>
>> Why is ClientProof  the result of ClientKey XOR ClientSignature ?
>> That  does that accomplish ?
>
> The server is able to calculate ClientSignature. From the ClientProof
> and that it can recover ClientKey, apply hash function once to get
> StoredKey and can verify that the client really knows the StoredKey
> (i.e. it knows the password).

What accomplishes that that HMAC(stored-key, auth-message) doesn't  
already.

Love



--Boundary_(ID_InNdRefGUqGpRtyQqY4FwQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite">Why is ClientProof &nbsp;the result of ClientKey XOR ClientSignature ? <br></blockquote><blockquote type="cite">That &nbsp;does that accomplish ?<br></blockquote><br>The server is able to calculate ClientSignature. From the ClientProof <br>and that it can recover ClientKey, apply hash function once to get <br>StoredKey and can verify that the client really knows the StoredKey <br>(i.e. it knows the password).<br></div></blockquote></div><br><div>What&nbsp;accomplishes&nbsp;that that HMAC(stored-key, auth-message) doesn't already.</div><div><br></div><div>Love</div><div><br></div><div><br></div></body></html>

--Boundary_(ID_InNdRefGUqGpRtyQqY4FwQ)--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22IZgd8084447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 11:35:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22IZgLg084446; Mon, 2 Mar 2009 11:35:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22IZVA7084434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 2 Mar 2009 11:35:42 -0700 (MST) (envelope-from [e-mail])
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 50D685733A3E for <[e-mail]>; Mon,  2 Mar 2009 10:35:31 -0800 (PST)
Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 276C12807D for <[e-mail]>; Mon,  2 Mar 2009 10:35:31 -0800 (PST)
X-AuditID: 1180711d-ac02cbb000000ff0-40-49ac26f26bbb
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with ESMTP id F19AA28094 for <[e-mail]>; Mon,  2 Mar 2009 10:35:30 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; delsp=yes; charset=us-ascii; format=flowed
Received: from [17.202.106.22] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <[e-mail]> for [e-mail]; Mon, 02 Mar 2009 10:35:30 -0800 (PST)
Subject: Re: [Fwd: I-D Action:draft-newman-auth-scram-10.txt]
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <[e-mail]>
Message-id: <[e-mail]>
In-reply-to: <[e-mail]>
Cc: SASL WG <[e-mail]>
Date: Mon, 02 Mar 2009 10:35:30 -0800
References: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
X-Mailer: Apple Mail (2.1047)
X-Brightmail-Tracker: AAAAAA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

No test vectors, specificly for the string2key function (which  
probably not is going to change).

Love




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22IILeE083586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 11:18:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22IIL5O083584; Mon, 2 Mar 2009 11:18:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22II9bu083571 for <[e-mail]>; Mon, 2 Mar 2009 11:18:19 -0700 (MST) (envelope-from [e-mail])
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:32909) by ppsw-5.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.155]:25) with esmtpa (EXTERNAL:fanf2) id 1LeCiN-0005H8-JG (Exim 4.70) (return-path <[e-mail]>); Mon, 02 Mar 2009 18:18:07 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1LeCiN-0001dP-Uw (Exim 4.67) (return-path <[e-mail]>); Mon, 02 Mar 2009 18:18:07 +0000
Date: Mon, 2 Mar 2009 18:18:07 +0000
From: Tony Finch <[e-mail]>
X-X-Sender: [e-mail]
To: Paul Romero <[e-mail]>
cc: [e-mail]
Subject: Re: TLS Requirement in SMTP RFC4954 and SASL
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>    <[e-mail]>  <[e-mail]>   <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 27 Feb 2009, Paul Romero wrote:
>
> CRAM-MD5 only specifies that  passwords/secrets are to be used
> as plaintext and not how they are stored.

Most non-plaintext stored passwords can't be decrypted for use in
plaintext form. (Again, see unix passwords.)

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22FRH7E071775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 08:27:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22FRHJC071774; Mon, 2 Mar 2009 08:27:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-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 n22FR6N5071762 for <[e-mail]>; Mon, 2 Mar 2009 08:27:16 -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 n22FR6jU026544 for <[e-mail]>; Mon, 2 Mar 2009 15:27:06 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n22FR6E1063628 for <[e-mail]>; Mon, 2 Mar 2009 08:27:06 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n22FI5e2012820; Mon, 2 Mar 2009 09:18:05 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22FI4Q7012819; Mon, 2 Mar 2009 09:18:04 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 2 Mar 2009 09:18:04 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: A SASL/GSS-API bridge in the *other* direction?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 02, 2009 at 09:50:09AM +0000, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Any SASL mechanism that uses cryptographic keys and has nonces could be
> >adapted to provide a "SASL PRF" [without changes to SASL apps] and so
> >any such mechanism could be used to build a GSS-API mechanism.
> >
> Right. I was thinking about doing something like this in relationship to 
> TLS.

Could you expand?  Did you mean using TLS as a SASL mechanism?  Or SASL
in TLS?  The latter is going to run into the same problems that TLS-GSS
did; we did discuss that in a jabber room or three at one or more IETF
meetings.

> >And any SASL mechanism that can provide a SASL PRF can be used to provide 
> >both
> >GSS-API channel binding and GSS-API per-message tokens.
> > 
> >
> >Is there any reason that a "SASL PRF" couldn't be constructed for
> >DIGEST-MD5, SCRAM, even CRAM-MD5?  I can't see one.
> >
> I can't think of any either.

OK.

Do you think that a SASL equivalent to RFC4401, and a DIGEST-MD5 and
SCRAM equivalent to RFC4402 is simple enough?

In order to keep round-trip counts down it's important to be able to
have equivalen support for GSS_C_PRF_KEY_FULL and GSS_C_PRF_KEY_PARTIAL
prf_key values in the SASL PRF.  For password-based mechanisms that's
trivially done.

> >Are there any other reasons why such a bridge would not be a good idea?
> >
> No, go for it :-).
> 
> >Principal naming issues, perhaps?
> >
> Can you elaborate?

Well, I was reaching -- wondering if there might be anything in SASL
mechanisms' principal naming that might be fatal for such a bridge, but
I can't think of anything.  E.g., DIGEST-MD5's notion of realm, or the
fact that SCRAM doesn't have one, but neither is a problem w.r.t.
GSS-API principal naming.

> >If such a bridge is doable we could just adopt Chris' pure SASL SCRAM
> >without further ado.

I await additional comments, but I'm reasonably sure that such a bridge
is quite doable.  Mechanism naming could be done mechanically by
encoding each SASL mechanism's name as OIDs :)  For example:

 - "SCRAM"'s bridged OID might become (yes, I'm being real cute here,
   encoding every pair of letters as an OID label, though one needn't
   stop at two):

   {1(iso), 3(org), 6(dod), 1(internet), 5(security),
       21313(gss-bridged-sa), 21315(sc), 21057(ra), 77(m)}

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 n22B2NYu055113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 04:02:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n22B2NXP055112; Mon, 2 Mar 2009 04:02:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n22B2LH0055105 for <[e-mail]>; Mon, 2 Mar 2009 04:02:21 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.187] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 2 Mar 2009 11:02:18 +0000
Message-ID: <[e-mail]>
Date: Mon, 02 Mar 2009 11:01:57 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Dave Cridland <[e-mail]>
CC: Nicolas Williams <[e-mail]>, [e-mail], [e-mail], Arnt Gulbrandsen <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <15219.1235820001.492969@invsysm1> <[e-mail]> <18794.1235904480.961002@invsysm1>
In-Reply-To: <18794.1235904480.961002@invsysm1>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland wrote:

> If I ruled the world, then - after mandating more important things  
> like food for all, world peace, and British spelling - I'd recast TLS  
> itself as a security layer extension within SASL, and/or extend SCRAM  
> with optional security layers.

BTW, the TLS-as-a-SASL-security-layer issue is so last century. The boat 
has sailed and sunk already.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n229oe1q050877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 02:50:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n229oePb050876; Mon, 2 Mar 2009 02:50: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 n229oSva050858 for <[e-mail]>; Mon, 2 Mar 2009 02:50:39 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.171.13] (92.40.171.13.sub.mbb.three.co.uk [92.40.171.13])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 2 Mar 2009 09:50:26 +0000
Message-ID: <[e-mail]>
Date: Mon, 02 Mar 2009 09:50:09 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <[e-mail]>
CC: [e-mail]
Subject: Re: A SASL/GSS-API bridge in the *other* direction?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>It seems to me that we could pursue a SASL/GSS-API bridge in the
>opposite direction of GS2, either in addition to or instead of GS2.
>
>SASL mechanisms, SASL being stream-oriented, are not well-suited to be
>being used as GSS-API mechanisms.  But perhaps there is a way.
>
>Certainly, any SASL mechanism that provides channel binding could at
>least be adapted as a GSS-API mechanism that provides channel binding
>but no GSS-API per-message tokens.
>  
>
Right.

>But also, any SASL mechanism that could be made to provide session
>keying for GSS-API per-message tokens could be used to key the per-
>message tokens specified by RFC4121 (the Kerberos V GSS mech).  All we'd
>need is the SASL equivalent of GSS_Pseudo_random() -- a SASL PRF.
>  
>
Indeed.

>Any SASL mechanism that uses cryptographic keys and has nonces could be
>adapted to provide a "SASL PRF" [without changes to SASL apps] and so
>any such mechanism could be used to build a GSS-API mechanism.
>
Right. I was thinking about doing something like this in relationship to 
TLS.

>And any SASL mechanism that can provide a SASL PRF can be used to provide both
>GSS-API channel binding and GSS-API per-message tokens.
>  
>
>Is there any reason that a "SASL PRF" couldn't be constructed for
>DIGEST-MD5, SCRAM, even CRAM-MD5?  I can't see one.
>
I can't think of any either.

>Are there any other reasons why such a bridge would not be a good idea?
>
No, go for it :-).

>Principal naming issues, perhaps?
>  
>
Can you elaborate?

>Thus we'd use GS2 to use the Kerberos V and PKU2U GSS-API mechanisms in
>SASL, and we'd use the bridge in the other direction to use DIGEST-MD5
>and SCRAM in GSS-API applications.
>
>If such a bridge is doable we could just adopt Chris' pure SASL SCRAM
>without further ado.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n226sH8S043561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 23:54:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n226sHTS043560; Sun, 1 Mar 2009 23:54:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n226sGVo043554 for <[e-mail]>; Sun, 1 Mar 2009 23:54:17 -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 n226sGe2018373 for <[e-mail]>; Mon, 2 Mar 2009 06:54:16 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n226sG96046001 for <[e-mail]>; Sun, 1 Mar 2009 23:54:16 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n226j9Zq012653 for <[e-mail]>; Mon, 2 Mar 2009 00:45:09 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n226j8OQ012652 for [e-mail]; Mon, 2 Mar 2009 00:45:08 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 2 Mar 2009 00:45:08 -0600
From: Nicolas Williams <[e-mail]>
To: [e-mail]
Subject: A SASL/GSS-API bridge in the *other* direction?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems to me that we could pursue a SASL/GSS-API bridge in the
opposite direction of GS2, either in addition to or instead of GS2.

SASL mechanisms, SASL being stream-oriented, are not well-suited to be
being used as GSS-API mechanisms.  But perhaps there is a way.

Certainly, any SASL mechanism that provides channel binding could at
least be adapted as a GSS-API mechanism that provides channel binding
but no GSS-API per-message tokens.

But also, any SASL mechanism that could be made to provide session
keying for GSS-API per-message tokens could be used to key the per-
message tokens specified by RFC4121 (the Kerberos V GSS mech).  All we'd
need is the SASL equivalent of GSS_Pseudo_random() -- a SASL PRF.

Any SASL mechanism that uses cryptographic keys and has nonces could be
adapted to provide a "SASL PRF" [without changes to SASL apps] and so
any such mechanism could be used to build a GSS-API mechanism.  And any
SASL mechanism that can provide a SASL PRF can be used to provide both
GSS-API channel binding and GSS-API per-message tokens.

Is there any reason that a "SASL PRF" couldn't be constructed for
DIGEST-MD5, SCRAM, even CRAM-MD5?  I can't see one.  Are there any other
reasons why such a bridge would not be a good idea?  Principal naming
issues, perhaps?

Thus we'd use GS2 to use the Kerberos V and PKU2U GSS-API mechanisms in
SASL, and we'd use the bridge in the other direction to use DIGEST-MD5
and SCRAM in GSS-API applications.

If such a bridge is doable we could just adopt Chris' pure SASL SCRAM
without further ado.

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 n21HDWJt098478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 10:13:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21HDWC1098477; Sun, 1 Mar 2009 10:13:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21HDBYl098428 for <[e-mail]>; Sun, 1 Mar 2009 10:13:22 -0700 (MST) (envelope-from [e-mail])
Received: from invsysm1 (93-96-137-178.zone4.bethere.co.uk [93.96.137.178]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Sun, 1 Mar 2009 17:14:02 +0000
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <15219.1235820001.492969@invsysm1> <[e-mail]> <18794.1235904484.407095@invsysm1> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <22869.1235927583.111152@invsysm1>
Date: Sun, 01 Mar 2009 17:13:03 +0000
From: Dave Cridland <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, Nicolas Williams <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun Mar  1 13:12:12 2009, Jeffrey Hutzelman wrote:
> --On Sunday, March 01, 2009 10:48:04 AM +0000 Dave Cridland  
> <[e-mail]> wrote:
> 
>> So, I've an implementation of SCRAM-HMAC-H for H in any of MD2 MD5  
>> SHA-*
>> that Python's hashlib supports. I don't even know what hashes are
>> supported.
> 
> I believe this is _exactly_ what we were trying to avoid by  
> specifying SCRAM-HMAC-SHA-1 rather than SCRAM-HMAC-<any_hash>.  if  
> your implementation advertises SCRAM-HMAC-SHA-2, and it ends up  
> getting used, than that will create interoperability problems if  
> the IETF eventually defines SCRAM-HMAC-SHA-2 and it ends up being  
> something other than SCRAM-HMAC-SHA-1 with the hash swapped out.

If SCRAM-HMAC-SHA-2 is not SCRAM-HMAC-SHA-1 with a IANA-registered  
SHA-2 instead of SHA-1, then I think we'll have interop problems  
anyway. You'd want it to be SCRAM2-HMAC-... or something, to avoid  
that barrel of laughs.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21HDOTA098465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 10:13:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21HDOHY098464; Sun, 1 Mar 2009 10:13:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21HDIkD098443 for <[e-mail]>; Sun, 1 Mar 2009 10:13:22 -0700 (MST) (envelope-from [e-mail])
Received: from invsysm1 (93-96-137-178.zone4.bethere.co.uk [93.96.137.178]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Sun, 1 Mar 2009 17:14:12 +0000
X-SMTP-Protocol-Errors: PIPELINING
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <22869.1235927593.493546@invsysm1>
Date: Sun, 01 Mar 2009 17:13:13 +0000
From: Dave Cridland <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, <[e-mail]>, <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, Nicolas Williams <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sun Mar  1 16:07:16 2009, Ned Freed wrote:
> I'm always a little leery of anecdotal evidence, but FWIW we have  
> found no
> reason to support SASL security layers. In fact not too long ago I  
> actually
> ripped out most of the latent support for security layers in our  
> SMTP client
> and server.  I was tired of navigating around all that complex  
> buffer handling.
> I was also concerned that due to minimal testing it had become a  
> nest of latent
> bugs waiting to bite us.

FWIW, we [Isode] do support SASL based security layers - I'm not  
arguing that they should go away entirely, I think they're extremely  
useful in some environments, and particularly in the GSS-API cases.

However, I think the complexity outweighs the utility in a SASL SCRAM  
mechanism.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21GC58l094752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 09:12:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21GC5lT094750; Sun, 1 Mar 2009 09:12:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21GBsKi094726 for <[e-mail]>; Sun, 1 Mar 2009 09:12:04 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 1 Mar 2009 08:11:52 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sun, 01 Mar 2009 08:11:48 -0800 (PST)
Date: Sun, 01 Mar 2009 08:07:16 -0800 (PST)
From: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
In-reply-to: "Your message dated Sat, 28 Feb 2009 15:38:33 -0600" <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail], Dave Cridland <[e-mail]>, [e-mail], Arnt Gulbrandsen <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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 Sat, Feb 28, 2009 at 09:25:52PM +0000, Alexey Melnikov wrote:
> > Nicolas Williams wrote:
> > >SASL must handle max buffer negotiation and security layers negotiation,
> > >right?  That's why I have that in GS2.  It means not having to have it
> > >in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).
> > >
> > No, it is not a bug. A SASL mechanism may choose not to provide any
> > security layer. But if it does, it must allow negotiation of the max
> > buffer size.

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

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

I'm always a little leery of anecdotal evidence, but FWIW we have found no
reason to support SASL security layers. In fact not too long ago I actually
ripped out most of the latent support for security layers in our SMTP client
and server.  I was tired of navigating around all that complex buffer handling.
I was also concerned that due to minimal testing it had become a nest of latent
bugs waiting to bite us.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21DEhdx088267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 06:14:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21DEg9s088266; Sun, 1 Mar 2009 06:14:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n21DEfbZ088259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 1 Mar 2009 06:14:42 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-236-105.pools.spcsdns.net (70-5-93-108.pools.spcsdns.net [70.5.93.108]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n21DEcwY008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 08:14:39 -0500 (EST)
Date: Sun, 01 Mar 2009 08:14:38 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Russ Allbery <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Saturday, February 28, 2009 02:21:08 PM -0600 Nicolas Williams 
<[e-mail]> wrote:

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

Except that you keep trying to remove the bit in the client's first message 
that says whether channel binding data is included, and you cannot do that. 
You can get by without it for SCRAM, but not for arbitrary GSS-API 
mechanisms, and so GS2 must include it.  Simple is good; too simple is 
fatal.

-- 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 n21DCV3P088167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 06:12:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21DCVPJ088166; Sun, 1 Mar 2009 06:12:31 -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 n21DCJLV088130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 1 Mar 2009 06:12:30 -0700 (MST) (envelope-from [e-mail])
Received: from 68-247-236-105.pools.spcsdns.net (70-5-93-108.pools.spcsdns.net [70.5.93.108]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n21DCCT8008121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 08:12:13 -0500 (EST)
Date: Sun, 01 Mar 2009 08:12:12 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Dave Cridland <[e-mail]>, Nicolas Williams <[e-mail]>
cc: [e-mail], [e-mail], Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <18794.1235904484.407095@invsysm1>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <15219.1235820001.492969@invsysm1> <[e-mail]> <18794.1235904484.407095@invsysm1>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Sunday, March 01, 2009 10:48:04 AM +0000 Dave Cridland 
<[e-mail]> wrote:

> So, I've an implementation of SCRAM-HMAC-H for H in any of MD2 MD5 SHA-*
> that Python's hashlib supports. I don't even know what hashes are
> supported.

I believe this is _exactly_ what we were trying to avoid by specifying 
SCRAM-HMAC-SHA-1 rather than SCRAM-HMAC-<any_hash>.  if your implementation 
advertises SCRAM-HMAC-SHA-2, and it ends up getting used, than that will 
create interoperability problems if the IETF eventually defines 
SCRAM-HMAC-SHA-2 and it ends up being something other than SCRAM-HMAC-SHA-1 
with the hash swapped out.

-- 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 n21B66Fh082988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 04:06:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21B66IQ082987; Sun, 1 Mar 2009 04:06:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21B5rja082974 for <[e-mail]>; Sun, 1 Mar 2009 04:06:04 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.177.223] (92.40.177.223.sub.mbb.three.co.uk [92.40.177.223])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 1 Mar 2009 11:05:51 +0000
Message-ID: <[e-mail]>
Date: Sun, 01 Mar 2009 11:05:39 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Nicolas Williams <[e-mail]>
CC: [e-mail]
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Sat, Feb 28, 2009 at 09:25:52PM +0000, Alexey Melnikov wrote:
>  
>
>>Nicolas Williams wrote:
>>    
>>
>>>SASL must handle max buffer negotiation and security layers negotiation,
>>>right?  That's why I have that in GS2.  It means not having to have it
>>>in SCRAM (is it a bug in Chris' I-D that SCRAM doesn't have these?).
>>>      
>>>
>>No, it is not a bug. A SASL mechanism may choose not to provide any 
>>security layer. But if it does, it must allow negotiation of the max 
>>buffer size.
>>    
>>
>Most who have commented since seem to be saying we don't want SCRAM to
>have sec layers -- that we must always do channel binding.
>  
>
Speaking as an individual:

Not having a SCRAM security layer is fine with me.

Having 2 variants of the SASL mechanism (one which requires channel 
binding and one which doesn't) is fine with me too. Not having the last 
choice is not.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21AmMpT082405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 03:48:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21AmMPM082403; Sun, 1 Mar 2009 03:48:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21Am92w082388 for <[e-mail]>; Sun, 1 Mar 2009 03:48:20 -0700 (MST) (envelope-from [e-mail])
Received: from invsysm1 (93-96-137-178.zone4.bethere.co.uk [93.96.137.178]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <SapoHQByYD=[e-mail]>; Sun, 1 Mar 2009 10:49:01 +0000
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <15219.1235820001.492969@invsysm1> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <18794.1235904480.961002@invsysm1>
Date: Sun, 01 Mar 2009 10:48:00 +0000
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat Feb 28 19:27:54 2009, Nicolas Williams wrote:
> I have an LDAP application that uses SASL/GSS-API with security  
> layers
> all the time.
> 
> 
Sure, I think the OpenLDAP libraries will do security layers, too, by  
using Cyrus SASL and actually including the additional magic to turn  
them on. I think this'd even be fairly commonplace with apps designed  
to use, say, Kerberos V.

But I still see you, me, and anyone else using seclayers as an  
insignificant minority in this matter. It's not even as if I like  
being insignificant, either.


> But sure, I second Jeff's call for a consensus on security layers.   
> If
> we agree we don't want them, then several bits of the GS2 headers go
> away.
> 
> 
I want them, I just don't think that, in practise, they'll be used.

I susect that much of this is because the notions of "secure" and  
"encrypted" are inextricably linked to TLS in the minds of the  
consumer, and the protocols that use SASL are often consumer-driven  
protocols, like email, instant messaging, etc. (LDAP's an exception  
here, so it wouldn't surprise me if LDAP sees plenty of use of  
security layers.)

If I ruled the world, then - after mandating more important things  
like food for all, world peace, and British spelling - I'd recast TLS  
itself as a security layer extension within SASL, and/or extend SCRAM  
with optional security layers.

But I suspect the whole seclayer thing's going to increase perceived  
complexity, and that's something I'm really averse to right now,  
while my status as ruler of the universe is still in some doubt.  
Application security is achievable to a reasonable level with  
SCRAM-HMAC-* and channel bindings, and that's good enough for now.

I still maintain that going after GS2-* compatibility is not the  
sensible goal here, incidentally. Aside from anything else, I suspect  
those environments which *do* wish to deploy GS2-* will also be  
wanting security layers - you're practically setting yourself up as a  
case in point, here. I think security layers are good, for many  
values of good, and I think that a GSS-API mechanism based on the  
same design as SCRAM would probably have security layers, and indeed  
they'd be used.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21AmMVT082406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Mar 2009 03:48:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n21AmMEb082404; Sun, 1 Mar 2009 03:48:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n21AmHw9082391 for <[e-mail]>; Sun, 1 Mar 2009 03:48:20 -0700 (MST) (envelope-from [e-mail])
Received: from invsysm1 (93-96-137-178.zone4.bethere.co.uk [93.96.137.178]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id <SapoIwByYJ3=@turner.dave.cridland.net>; Sun, 1 Mar 2009 10:49:07 +0000
X-SMTP-Protocol-Errors: PIPELINING
Subject: Re: New GS2 design -- much simplified, and simplified SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <15219.1235820001.492969@invsysm1> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <18794.1235904484.407095@invsysm1>
Date: Sun, 01 Mar 2009 10:48:04 +0000
From: Dave Cridland <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, Jeffrey Hutzelman <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat Feb 28 19:27:54 2009, Nicolas Williams wrote:
> http://www.iana.org/assignments/channel-binding-types/tls-unique

Assuming it's this one, I'm done. (In well under ten minutes, I just  
had to delete one line).

So, I've an implementation of SCRAM-HMAC-H for H in any of MD2 MD5  
SHA-* that Python's hashlib supports. I don't even know what hashes  
are supported. Four hours, probably one of which was spent reading  
multiple I-Ds to try and figure out what TLS channel binding data was  
needed.

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