Re: GSS init tok header compression (Re: SCRAM and mechanism family)

[Simon Josefsson <[e-mail]>]

Arnt Gulbrandsen <[e-mail]> writes:

> Nicolas Williams writes:
>> That was Sam's point -- the OS can provide SASL and GSS frameworks,
>> but there's no way to force third parties to use them.
>>
>> Now, one possible answer is: not our problem. But I don't like that answer.
>
> I don't understand.
>
> What's the point of the hashed OIDs as names? I thought you were
> saying that their advantage is that they permit such applications to
> use new GS2 mechanisms.
>
> In my experience that's pointless. Those applications explicitly don't
> want to use new mechanisms, so making it easy is pointless. You seem
> to agree, or am I misreading? But what's the point of the hashing
> then?

I don't see it either.

I think there can even be security consequences in making it "too easy"
for GSS-API mechanisms to show up automatically as SASL mechanisms.

By requiring IANA registration, there is at least some minimal checks in
that some set of people have wanted to use a particular GSS-API
mechanism in SASL and went through the (hopefully simple) process to
register a SASL name.

Automatic export of GSS-API mechanisms into the SASL namespace seems
useful in theory, but I fail to see practical situations where it is
worthwhile.  There are not many GSS-API mechanisms out there, even fewer
are publicly standardized.

Proprietary GSS-API mechanisms can use a X-FOOBAR SASL mechanism name in
their own internal deployments too.  So if someone doesn't want to go
through the problem of IANA registration, they don't need too.  It is
only when interoperability is needed that you need a standardized SASL
mechname.

I don't object strongly to the hashed-mech-name idea.  But I would not
implement it -- instead I will hardcode the pre-computed GS2 SASL names
of known GSS-API mechanisms.

It would be interesting to hear from implementers that wants this
feature.

/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 mASE77vK009159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 07:07:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mASE77lU009158; Fri, 28 Nov 2008 07:07:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mASE74Pr009150 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 28 Nov 2008 07:07:06 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L63zn-0001T9-0A for [e-mail]; Fri, 28 Nov 2008 14:06:59 +0000
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 28 Nov 2008 14:06:58 +0000
Received: from simon by c80-216-27-189.bredband.comhem.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 28 Nov 2008 14:06:58 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  Simon Josefsson <[e-mail]>
Subject:  Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Date:  Fri, 28 Nov 2008 15:06:42 +0100
Lines: 48
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c80-216-27-189.bredband.comhem.se
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081128:gmane.ietf.sasl::vrc1PBWxXzRZuYtJ:Jhzd
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)
Cancel-Lock: sha1:tJ2Tajt1AcPEeSLQnkRWPaNKduA=
Sender: [e-mail]
Precedence: 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:

> Nicolas Williams writes:
>> That was Sam's point -- the OS can provide SASL and GSS frameworks,
>> but there's no way to force third parties to use them.
>>
>> Now, one possible answer is: not our problem. But I don't like that answer.
>
> I don't understand.
>
> What's the point of the hashed OIDs as names? I thought you were
> saying that their advantage is that they permit such applications to
> use new GS2 mechanisms.
>
> In my experience that's pointless. Those applications explicitly don't
> want to use new mechanisms, so making it easy is pointless. You seem
> to agree, or am I misreading? But what's the point of the hashing
> then?

I don't see it either.

I think there can even be security consequences in making it "too easy"
for GSS-API mechanisms to show up automatically as SASL mechanisms.

By requiring IANA registration, there is at least some minimal checks in
that some set of people have wanted to use a particular GSS-API
mechanism in SASL and went through the (hopefully simple) process to
register a SASL name.

Automatic export of GSS-API mechanisms into the SASL namespace seems
useful in theory, but I fail to see practical situations where it is
worthwhile.  There are not many GSS-API mechanisms out there, even fewer
are publicly standardized.

Proprietary GSS-API mechanisms can use a X-FOOBAR SASL mechanism name in
their own internal deployments too.  So if someone doesn't want to go
through the problem of IANA registration, they don't need too.  It is
only when interoperability is needed that you need a standardized SASL
mechname.

I don't object strongly to the hashed-mech-name idea.  But I would not
implement it -- instead I will hardcode the pre-computed GS2 SASL names
of known GSS-API mechanisms.

It would be interesting to hear from implementers that wants this
feature.

/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 mASDOmVF006742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 06:24:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mASDOmMY006741; Fri, 28 Nov 2008 06:24:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mASDOZZO006727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 28 Nov 2008 06:24:47 -0700 (MST) (envelope-from [e-mail])
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L63Kh-0008So-Fx for [e-mail]; Fri, 28 Nov 2008 13:24:31 +0000
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 28 Nov 2008 13:24:31 +0000
Received: from simon by c80-216-27-189.bredband.comhem.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Fri, 28 Nov 2008 13:24:31 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  Simon Josefsson <[e-mail]>
Subject:  Re: SCRAM "mandatory extensions"?
Date:  Fri, 28 Nov 2008 14:24:17 +0100
Lines: 34
Message-ID:  <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c80-216-27-189.bredband.comhem.se
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081128:gmane.ietf.sasl::z5UzcSJCTgXRldwJ:Okui
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)
Cancel-Lock: sha1:BS0NQIpur3iNYY1kZvj5Bs/tCGc=
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>> I'd prefer to avoid it, the SASL framework (and GSS-API
>> too, for that matter) is extensible, no need to reproduce
>> that in each mechanism too.
>
> Well, SASL limitations have come up, like my desire for a server
> to be able to respond "for this user, try this mecanism/SCRAM
> hash instead".  But that's not a mechanism-specific problem.
> I think I'm gonna sit on the fence for that one.

I thought more about a potential QUERY mechanism, and I see three
problems with it.  I think the problems can be solved, but they reduce
the neatness of the idea:

1) Authentication identities is a mechanism-specific concept.  However,
this could be solved by simply saying that a server is responsible for
querying all supported mechanisms whether the associated username is
known or not, and then potentially list a number of SASL mechanisms that
may support that particular username.

2) The list of mechanisms to return is not integrity protected.  This
can be solved by saying that QUERY is only useful with TLS and when the
eventually used SASL mechanism checks channel bindings.

3) Should the QUERY mechanism pseudo-authentication step fail or
succeed?  What happens on SASL mechanism failures is somewhat
implementation specific, and may be application protocol specific, so it
needs to be discussed and tested how it works in practice.

I would be interested in helping documenting and implementing a QUERY
mechanism though, if others are interested in it...

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mASDNwP0006628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 06:23:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mASDNw9I006627; Fri, 28 Nov 2008 06:23:58 -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 mASDNkRv006602 for <[e-mail]>; Fri, 28 Nov 2008 06:23:57 -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 75FE74AC6D; Fri, 28 Nov 2008 14:23:42 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1227878621-6222-1/6/1 (3 recipients); Fri, 28 Nov 2008 14:23:41 +0100
Message-Id: <[e-mail]>
Date: Fri, 28 Nov 2008 14:23:43 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Cc: [e-mail]
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams writes:
> That was Sam's point -- the OS can provide SASL and GSS frameworks, 
> but there's no way to force third parties to use them.
>
> Now, one possible answer is: not our problem. But I don't like that answer.

I don't understand.

What's the point of the hashed OIDs as names? I thought you were saying 
that their advantage is that they permit such applications to use new 
GS2 mechanisms.

In my experience that's pointless. Those applications explicitly don't 
want to use new mechanisms, so making it easy is pointless. You seem to 
agree, or am I misreading? But what's the point of the hashing then?

Maybe I'm dense. Sorry if so.

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 mARD3HKX018162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 06:03:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mARD3Hnj018161; Thu, 27 Nov 2008 06:03:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARD3Fkw018152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 27 Nov 2008 06:03:16 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1L5gWY-00047F-Rn; Thu, 27 Nov 2008 14:03:14 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx2.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1L5gWY-0003dw-Kf; Thu, 27 Nov 2008 14:03:14 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1L5gWY-000138-Fc; Thu, 27 Nov 2008 14:03:14 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 27 Nov 2008 14:03:14 +0100
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM "mandatory extensions"?
In-Reply-To: <[e-mail]>
References: <[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: CA0DD58A0A0EAC2EDACB26D79E70FEDEF2832CE7
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1282 max/h 8 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> It looks like future extensibility to me.

Yes.  I should have said, I don't see what good the m= field does.
The draft has a field with optional extensions too.

> I'd prefer to avoid it, the SASL framework (and GSS-API
> too, for that matter) is extensible, no need to reproduce
> that in each mechanism too.

Well, SASL limitations have come up, like my desire for a server
to be able to respond "for this user, try this mecanism/SCRAM
hash instead".  But that's not a mechanism-specific problem.
I think I'm gonna sit on the fence for that one.

-- 
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 mARCAL55013276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 05:10:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mARCALl6013275; Thu, 27 Nov 2008 05:10:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARCA7CZ013227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 27 Nov 2008 05:10:19 -0700 (MST) (envelope-from [e-mail])
Received: from root by ciao.gmane.org with local (Exim 4.43) id 1L5fh4-0002EV-L4 for [e-mail]; Thu, 27 Nov 2008 12:10:02 +0000
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 27 Nov 2008 12:10:02 +0000
Received: from simon by c80-216-27-189.bredband.comhem.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <[e-mail]>; Thu, 27 Nov 2008 12:10:02 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: [e-mail]
From:  Simon Josefsson <[e-mail]>
Subject:  Re: SCRAM "mandatory extensions"?
Date:  Thu, 27 Nov 2008 13:04:29 +0100
Lines: 31
Message-ID:  <[e-mail]>
References:  <[e-mail]>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
X-Complaints-To: [e-mail]
X-Gmane-NNTP-Posting-Host: c80-216-27-189.bredband.comhem.se
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081127:gmane.ietf.sasl::A3lqoMj4kgvB4m+5:0efC
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)
Cancel-Lock: sha1:EI2OPiOj9TMFOXZRM1jtrDPF5uY=
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

> I don't understand the purpose of the SCRAM "m" (mandatory extensions)
> field.  The scram-07 draft says:
>
>   - m: Presence of this attribute in a client or a server message MUST
>     cause authentication failure when the attribute is parsed by the
>     other end.  The purpose of this attribute is to describe list of
>     mandatory extensions to SCRAM that the other end must support.
>     This attribute is reserved for future extensibility.
>
> What's the server supposed to use this information for?  Return a "m="
> message to the client about what extensions it does support?  If so that
> could be useful, but for other mechanisms too.  So I think a new SASL
> mechanism QUERY would be better.  The parameters could include an
> optional mechanism name if one wants to ask about a specific mechanism.
>
> As for "m=" sent to the client - if it's in response to an "m=" from the
> client, that's covered by QUERY above.  If it's not - then it seems to
> me the server will have announced that it supports SCRAM, only to reply
> "no, not ordinary SCRAM" when the client tries to use it.  Seems to me
> that could be more cleanly achieved by defining another mechanism
> consisting of SCRAM + the extension.
>
> Am I missing something?

It looks like future extensibility to me.  I'd prefer to avoid it, the
SASL framework (and GSS-API too, for that matter) is extensible, no need
to reproduce that in each mechanism 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 mARB3J1S005917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2008 04:03:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mARB3JpU005916; Thu, 27 Nov 2008 04:03:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mARB36Sa005884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 27 Nov 2008 04:03:18 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1L5eeH-0004SV-DI for [e-mail]; Thu, 27 Nov 2008 12:03:05 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx4.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1L5eeH-0003I5-6I for [e-mail]; Thu, 27 Nov 2008 12:03:05 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1L5eeG-0000oW-UR for [e-mail]; Thu, 27 Nov 2008 12:03:04 +0100
Message-Id: <[e-mail]>
From: Hallvard B Furuseth <[e-mail]>
To: [e-mail]
Subject: SCRAM "mandatory extensions"?
Date: Thu, 27 Nov 2008 12:03:04 +0100
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: CBD51FC0D499F91684E21C5F9629C9C63B5A6CAF
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1281 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>

I don't understand the purpose of the SCRAM "m" (mandatory extensions)
field.  The scram-07 draft says:

  - m: Presence of this attribute in a client or a server message MUST
    cause authentication failure when the attribute is parsed by the
    other end.  The purpose of this attribute is to describe list of
    mandatory extensions to SCRAM that the other end must support.
    This attribute is reserved for future extensibility.

What's the server supposed to use this information for?  Return a "m="
message to the client about what extensions it does support?  If so that
could be useful, but for other mechanisms too.  So I think a new SASL
mechanism QUERY would be better.  The parameters could include an
optional mechanism name if one wants to ask about a specific mechanism.

As for "m=" sent to the client - if it's in response to an "m=" from the
client, that's covered by QUERY above.  If it's not - then it seems to
me the server will have announced that it supports SCRAM, only to reply
"no, not ordinary SCRAM" when the client tries to use it.  Seems to me
that could be more cleanly achieved by defining another mechanism
consisting of SCRAM + the extension.

Am I missing something?

-- 
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 mAQHa6VU051611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 10:36:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAQHa6An051610; Wed, 26 Nov 2008 10:36:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQHZrY3051598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 26 Nov 2008 10:36:04 -0700 (MST) (envelope-from [e-mail])
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L5OIk-0005W9-GO; Wed, 26 Nov 2008 12:35:46 -0500
Date: Wed, 26 Nov 2008 12:35:45 -0500
From: John C Klensin <[e-mail]>
To: Simon Josefsson <[e-mail]>, Paul Smith <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, 26 November, 2008 17:52 +0100 Simon Josefsson
<[e-mail]> wrote:

> Paul Smith <[e-mail]> writes:
> 
>> CRAM-MD5 makes it a lot harder for MITM attacks than plain
>> text over an unverified TLS link does. While plain text over
>> TLS does stop attacks from 'eavesdroppers' it does nothing
>> for MITM attacks in most cases.
> 
> I hesitated to correct John about this, but if similar claims
> are repeated, I think we need to establish that CRAM-MD5 does
> not help against an MITM.

You can correct me any time you like, especially when I use
imprecise language.

To oversimplify somewhat, there are several possible attacks
that some people might describe in MITM terms.   One involves
impersonating the client and its credentials.   Without getting
into a debate about which Challenge-Response (CR) mechanism is
better than others, CR provides some protection against that
type of attach.  Another involves impersonating the server to
the client.  CR provides some protection there too.  And, in
both cases, it provides that protection even without
cryptography in general and session privacy protection in
particular.

Because session or link encryption (or the equivalent) are not
intrinsic to any CR method, they provide no protection against
session interception, especially of the passive data recording
(e.g., wiretapping) variety.  If the MITM attacker intends to do
anything more active, periodically reissuing the challenge can
make her life considerably more difficult although certainly not
impossible.

> CRAM-MD5 does not provide session security.  Thus an MITM can
> simply wait after the correct user has authenticated, and then
> hijack the session.  The attacker then has full access to the
> users' account.

As long as the MITM has the ability to do that, certainly yes.
To the extent to which the tools available to an MITM involve
hijacking by diversion of sessions at setup time, no.  And,
again depending on repeated challenge patterns and the nature of
the underlying application protocol, the MITM may be able to
monitor the transaction stream but may have only limited ability
to issue its own commands to the server and account.     Let's
remember that CR mechanisms, especially when used alone, have
never been legitimately considered as complete security
solutions, only as possibly-decent authentication ones when the
alternative is "nothing".  Conversely, let's not trick ourselves
into believing that all MITM attackers have access to seize any
connection, control the network, and fully operate any link they
can gain access to.

> The conclusion is that CRAM-MD5 needs TLS to protect against
> MITM's.

It needs properly authenticated TLS or some other session or
link encryption mechanism.   Without the "properly
authenticated" part, the MITM is free to divert the connection
and simply simulate the server.   And, of course, DNS attacks to
arrange such diversions are the easiest of MITM attacks to
arrange.  

> I believe TLS + CRAM-MD5 is better than TLS + PLAIN.  With TLS
> + CRAM-MD5, the MITM at least does not learn the long-term
> secret to set up new sessions.

And, with properly authenticated TLS (or
equally-well-authenticated IPSEC), the risks are further reduced
because one then has host-to-host protection of the data stream
and user-to-account authentication to use as the basis for
authorization.   Of course, a symmetric CR model would be even
better, if one could get it deployed.

Once again, I'm not trying to defend CRAM-MD5, or any other CR
mechanism, as either session security or as a really strong
authentication method.  I do contend that, as an authentication
mechanism, it is significantly better than nothing.  I also
believe that the evidence so far about the security differences
among CR mechanisms is that we need a lot more analysis of
operational risks  --not just analysis of how one technique
might be slightly better than another-- to justify trying to
discard (or recommend that people stop using) one method that is
widely deployed in favor of one that is still untested in
practice.

I also recommend against getting two hung up on CR+TLS as a
requirement, not because it isn't a good idea, but because we
have a bunch of other link and session encryption methods
available to us that may provide effective session security at
least as good as TLS (especially weakly-authenticated TLS), and
because, as far as I know, we have never demonstrated that
double encryption is desirable in the general case.  Telling
folks that CR doesn't really offer string protection without
pre-established session encryption is one thing; insisting on
TLS is something else entirely.

    john



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQGr3l9049706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 09:53:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAQGr3ot049705; Wed, 26 Nov 2008 09:53:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQGqoqk049685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 26 Nov 2008 09:53:02 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L5Nd7-0000Se-Jl; Wed, 26 Nov 2008 17:52:46 +0100
From: Simon Josefsson <[e-mail]>
To: Paul Smith <[e-mail]>
Cc: John C Klensin <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081126:[e-mail]::ft/GM0jDOBE6yp11:1Uv0
X-Hashcash: 1:22:081126:[e-mail]::D2WJaZcz5gBmfH4g:7bv/
X-Hashcash: 1:22:081126:[e-mail]::7leP0JdE2e7ZYavy:5mO5
X-Hashcash: 1:22:081126:[e-mail]::gjHkQE4sBm2T2xkx:IbVL
X-Hashcash: 1:22:081126:[e-mail]::V0hlcKyxR3EKD26A:G5Dj
Date: Wed, 26 Nov 2008 17:52:44 +0100
In-Reply-To: <[e-mail]> (Paul Smith's message of "Wed, 26 Nov 2008 16:30:12 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Smith <[e-mail]> writes:

> CRAM-MD5 makes it a lot harder for MITM attacks than plain text over an
> unverified TLS link does. While plain text over TLS does stop attacks
> from 'eavesdroppers' it does nothing for MITM attacks in most cases.

I hesitated to correct John about this, but if similar claims are
repeated, I think we need to establish that CRAM-MD5 does not help
against an MITM.

CRAM-MD5 does not provide session security.  Thus an MITM can simply
wait after the correct user has authenticated, and then hijack the
session.  The attacker then has full access to the users' account.

The conclusion is that CRAM-MD5 needs TLS to protect against MITM's.

I believe TLS + CRAM-MD5 is better than TLS + PLAIN.  With TLS +
CRAM-MD5, the MITM at least does not learn the long-term secret to set
up new sessions.

/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 mAQGoto3049614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 09:50:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAQGotlX049613; Wed, 26 Nov 2008 09:50:55 -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 mAQGohx6049593 for <[e-mail]>; Wed, 26 Nov 2008 09:50:54 -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 mAQGoh1e010367 for <[e-mail]>; Wed, 26 Nov 2008 16:50: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 mAQGohH7049277 for <[e-mail]>; Wed, 26 Nov 2008 09:50:43 -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 mAQGgRtS019766; Wed, 26 Nov 2008 10:42:27 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAQGgNiO019765; Wed, 26 Nov 2008 10:42:23 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 26 Nov 2008 10:42:23 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Nov 26, 2008 at 11:05:18AM +0100, Arnt Gulbrandsen wrote:
> Nicolas Williams writes:
> >Now, you can expect GSS mechanisms packaged and delivered by that 
> >operating system's maintainers to update the GSS-API library's 
> >mechanism registration and the SASL library's, but you can't expect 
> >them to update your application's gsasl mechanism registration.
> 
> If my experience is anything to go by (FWIW I was a library person in a 
> past life), then you also can't expect such application vendors to want 
> to use new mechanisms.
> 
> Many of our customers who shipped private copies of libraries, and they 
> generally wanted to use only what was in them, not anything more. For 
> good reason.

That was Sam's point -- the OS can provide SASL and GSS frameworks, but
there's no way to force third parties to use them.

Now, one possible answer is: not our problem.  But I don't like that
answer.

> >That was the example Sam gave me. I think it's quite likely to happen. 
> >I think it will be best to avoid it (i.e., Sam convinced me that at 
> >least all future GSS-API mechanisms should have SASL/GS2 names 
> >derived from their OIDs). Sam did propose an alternative: extend the 
> >GSS-API to provide a function for looking up a GSS mechanism's 
> >registered SASL/GS2 name, but I don't think anyone will be 
> >enthustiastic about that.
> 
> I don't see a lot of enthusiasm for the hashed names either.

Ah, see, I knew that.  But a choice still has to be made.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQGUbhA048858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 09:30:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAQGUbfQ048857; Wed, 26 Nov 2008 09:30:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.pscs.co.uk (mail.pscs.co.uk [77.240.14.73]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQGUORk048848 for <[e-mail]>; Wed, 26 Nov 2008 09:30:36 -0700 (MST) (envelope-from [e-mail])
Received: from lmail.pscs.co.uk ([62.3.195.6]) by mail.pscs.co.uk ([77.240.14.73] running VPOP3) with ESMTP; Wed, 26 Nov 2008 16:30:16 -0000
Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Wed, 26 Nov 2008 16:30:12 -0000
Message-ID: <[e-mail]>
Date: Wed, 26 Nov 2008 16:30:12 +0000
From: Paul Smith <[e-mail]>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: John C Klensin <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V2.6.0e - Registered
X-Organisation: Paul Smith Computer Services
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John C Klensin wrote:
> I would certainly agree with that conclusion about clear-text
> over TLS if it were substantiated.  However, in a world in which
> typical certs for mail servers seem to be either self-signed (or
> certified on the basis of email address dialogues or domain name
> ownership), in which attacks on the DNS are well-known and the
> proper response to "Bind 8 is dead" may be "before or after Bind
> 4?", methods based on challenge-response may have one advantage
> that the I-D does not discuss, namely being independent of the
> certificate and DNS situation and relationships.  
>   
I think this is an important issue. So, I agree with John's 'plan of
attack' here.

CRAM-MD5 makes it a lot harder for MITM attacks than plain text over an
unverified TLS link does. While plain text over TLS does stop attacks
from 'eavesdroppers' it does nothing for MITM attacks in most cases.

I think one thing that some people seem to forget is that most people
who use email have no clue what TLS is, or how certificates work. For
plain text over TLS to be more secure (IMV) than CRAM-MD5, average users
would have to check mail server certificates, which they won't do.

- I can see the point in the draft about an a priori agreement about
character set, but is that really a big deal? 'sequence of ASCII
printable characters encoded in an octet with zero parity, with no
normalization' pretty much covers every case of passwords I've ever seen
anyone use - even in non-latin character set countries.

- No, CRAM-MD5 doesn't protect the user ID from eavesdroppers, but plain
text over TLS protects neither the user ID nor the password from a MITM
attack if the certificate isn't verified. CRAM-MD5 does protect the
password from both eavesdroppers and MITM attacks. Given that a large
number of mail providers use easily guessable user IDs (for ease of use
by users), I'm not sure how significant this 'weakness' in CRAM-MD5 is
*in real life*.

Now, in *some cases* I can see that plain text/TLS is better than
CRAM-MD5 - where the mail system is managed by competent techies, and
where email software is installed for users by those techies (so
certificates can be configured properly), but in the vast majority of
cases out there, I think the choice would be CRAM-MD5, plain text over
an unencrypted session, or plain text over a dubiously encrypted session
- which is better?

CRAM-MD5 has a large deployed server base out there. I don't think PLAIN
over TLS is a secure alternative, and SCRAM is still 'work in progress'
(and I remember the issues that we STILL have because we deployed SMTP
'AUTH' support before that was finalised ('AUTH=CRAM-MD5' vs 'AUTH
CRAM-MD5' anyone?)).

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAQA6Ljf025642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Nov 2008 03:06:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAQA6Lqc025641; Wed, 26 Nov 2008 03:06:21 -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 mAQA68ad025627 for <[e-mail]>; Wed, 26 Nov 2008 03:06:20 -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 3A5EB4AC1B; Wed, 26 Nov 2008 11:06:07 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.4) with esmtp id 1227693966-55372-1/6/16 (3 recipients); Wed, 26 Nov 2008 11:06:06 +0100
Message-Id: <[e-mail]>
Date: Wed, 26 Nov 2008 11:05:18 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: Nicolas Williams <[e-mail]>
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Cc: [e-mail]
References: <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[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]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams writes:
> On Tue, Nov 25, 2008 at 11:09:17PM +0100, Arnt Gulbrandsen wrote:
>>  What are some applications that implement their own SASL framework, 
>>  would need updates to support new SASL mechanisms, and would NOT 
>>  need updates to support new SASL/GS2 mechanisms?
>
> Today: none.
>
> However, suppose you've written some application using GNU SASL 
> (libgsasl) and you want to build and run it on some operating system 
> where the system-provided SASL library is, say, Cyrus SASL 
> (libsasl2). You may not want to port to libsasl2. You may want to 
> just ship your app linked with a private copy of libgsasl (which 
> you'd also ship along with your app).
>
> Now, you can expect GSS mechanisms packaged and delivered by that 
> operating system's maintainers to update the GSS-API library's 
> mechanism registration and the SASL library's, but you can't expect 
> them to update your application's gsasl mechanism registration.

If my experience is anything to go by (FWIW I was a library person in a 
past life), then you also can't expect such application vendors to want 
to use new mechanisms.

Many of our customers who shipped private copies of libraries, and they 
generally wanted to use only what was in them, not anything more. For 
good reason.

> That was the example Sam gave me. I think it's quite likely to happen. 
> I think it will be best to avoid it (i.e., Sam convinced me that at 
> least all future GSS-API mechanisms should have SASL/GS2 names 
> derived from their OIDs). Sam did propose an alternative: extend the 
> GSS-API to provide a function for looking up a GSS mechanism's 
> registered SASL/GS2 name, but I don't think anyone will be 
> enthustiastic about that.

I don't see a lot of enthusiasm for the hashed names either.

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 mAPNd7wI093033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 16:39:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPNd70R093032; Tue, 25 Nov 2008 16:39:07 -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 mAPNd6Wp093025 for <[e-mail]>; Tue, 25 Nov 2008 16:39:06 -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 mAPNd6fp013735 for <[e-mail]>; Tue, 25 Nov 2008 23:39:06 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 mAPNd69g019549 for <[e-mail]>; Tue, 25 Nov 2008 16:39: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 mAPNUqBv019346; Tue, 25 Nov 2008 17:30:52 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPNUqst019345; Tue, 25 Nov 2008 17:30:52 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 17:30:52 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Nov 26, 2008 at 12:16:16AM +0100, Simon Josefsson wrote:
> What kind of application would be able to take advantage of the new
> GSS-API mechanism?

CLient apps.

> Most SASL applications are rather tightly coupled with the SASL
> mechanism in order to do auditing (logging), authorization,
> leap-of-faith trust, and possibly other mechanism-specific operations.

Yes, but that's all server side.  Not that anything stops you from
writing a server app that uses GNU SASL on a system that ships with
Cyrus SASL, yet still use the system's GSS-API framework -- you'd just
not benefit from whatever integrated auditing, ... the system's SASL
framework provides.

> If an application or SASL library notices that an unknown GSS-API
> mechanism is available, I don't see how applications or SASL libraries
> could use that mechanism without additional APIs that doesn't exist
> today -- APIs such as "does this mechanism use X.509?" which would allow
> the application to do something reasonable with the X.509 credentials.

I think client apps would just work.  Much the same is true for simple
GSS apps.  E.g., I didn't have to add any mech-specific code to SunSSH to
make it use any GSS mech shipped with Solaris, though I did have to
hard-code SPNEGO's OID because SSHv2 w/ GSS is not allowed to use
SPNEGO and I had no better way to detect if a mechanism was SPNEGO.

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 mAPNGRnY091885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 16:16:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPNGRgp091884; Tue, 25 Nov 2008 16:16:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPNGP35091878 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 16:16:26 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L578o-0000Bt-5q; Wed, 26 Nov 2008 00:16:23 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
References: <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[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:081125:[e-mail]::yK90Wv2IMmaYWjh+:DXWN
X-Hashcash: 1:22:081125:[e-mail]::bZEujN7+Sqe6RGG/:Wv0N
X-Hashcash: 1:22:081125:[e-mail]::6YD7fd5ngJyq8FnS:mIRR
Date: Wed, 26 Nov 2008 00:16:16 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 25 Nov 2008 16:38:18 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Nov 25, 2008 at 11:09:17PM +0100, Arnt Gulbrandsen wrote:
>> What are some applications that implement their own SASL framework, 
>> would need updates to support new SASL mechanisms, and would NOT need 
>> updates to support new SASL/GS2 mechanisms?
>
> Today: none.
>
> However, suppose you've written some application using GNU SASL
> (libgsasl) and you want to build and run it on some operating system
> where the system-provided SASL library is, say, Cyrus SASL (libsasl2).
> You may not want to port to libsasl2.  You may want to just ship your
> app linked with a private copy of libgsasl (which you'd also ship along
> with your app).
>
> Now, you can expect GSS mechanisms packaged and delivered by that
> operating system's maintainers to update the GSS-API library's mechanism
> registration and the SASL library's, but you can't expect them to update
> your application's gsasl mechanism registration.

What kind of application would be able to take advantage of the new
GSS-API mechanism?

Most SASL applications are rather tightly coupled with the SASL
mechanism in order to do auditing (logging), authorization,
leap-of-faith trust, and possibly other mechanism-specific operations.

If an application or SASL library notices that an unknown GSS-API
mechanism is available, I don't see how applications or SASL libraries
could use that mechanism without additional APIs that doesn't exist
today -- APIs such as "does this mechanism use X.509?" which would allow
the application to do something reasonable with the X.509 credentials.
Another API would be "does the mechanism uses passwords?", which would
allow the application and SASL library to treat it similar to existing
password mechanisms.

While nice in theory, I'm yet to be convinced that automatic support for
unknown GSS-API mechanisms in applications is something that is even
close to becoming a reality.

/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 mAPMkm4Z090263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 15:46:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPMkmEf090260; Tue, 25 Nov 2008 15:46:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPMkamp090248 for <[e-mail]>; Tue, 25 Nov 2008 15:46:46 -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 mAPMkZNX026938 for <[e-mail]>; Tue, 25 Nov 2008 22:46:35 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 mAPMkZFX030305 for <[e-mail]>; Tue, 25 Nov 2008 15:46:35 -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 mAPMcL4R019252; Tue, 25 Nov 2008 16:38:21 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPMcIF4019251; Tue, 25 Nov 2008 16:38:18 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 16:38:18 -0600
From: Nicolas Williams <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Message-ID: <[e-mail]>
References: <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 25, 2008 at 11:09:17PM +0100, Arnt Gulbrandsen wrote:
> What are some applications that implement their own SASL framework, 
> would need updates to support new SASL mechanisms, and would NOT need 
> updates to support new SASL/GS2 mechanisms?

Today: none.

However, suppose you've written some application using GNU SASL
(libgsasl) and you want to build and run it on some operating system
where the system-provided SASL library is, say, Cyrus SASL (libsasl2).
You may not want to port to libsasl2.  You may want to just ship your
app linked with a private copy of libgsasl (which you'd also ship along
with your app).

Now, you can expect GSS mechanisms packaged and delivered by that
operating system's maintainers to update the GSS-API library's mechanism
registration and the SASL library's, but you can't expect them to update
your application's gsasl mechanism registration.

That was the example Sam gave me.  I think it's quite likely to happen.
I think it will be best to avoid it (i.e., Sam convinced me that at
least all future GSS-API mechanisms should have SASL/GS2 names derived
from their OIDs).  Sam did propose an alternative: extend the GSS-API to
provide a function for looking up a GSS mechanism's registered SASL/GS2
name, but I don't think anyone will be enthustiastic about that.

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 mAPMhPrr090078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 15:43:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPMhPr0090077; Tue, 25 Nov 2008 15:43:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPMhN7M090068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 15:43:24 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L56cq-0000BL-1Q; Tue, 25 Nov 2008 23:43:20 +0100
From: Simon Josefsson <[e-mail]>
To: John C Klensin <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081125:[e-mail]::kZWKc0Gk9a2hqln6:2Lab
X-Hashcash: 1:22:081125:[e-mail]::J5NXSItRerHfvr28:6HM1
X-Hashcash: 1:22:081125:[e-mail]::iDiD6V9HARS/r0V8:8Yc8
X-Hashcash: 1:22:081125:[e-mail]::SQroV9NCLCMVGfcw:cb4A
Date: Tue, 25 Nov 2008 23:43:19 +0100
In-Reply-To: <[e-mail]> (John C. Klensin's message of "Tue, 25 Nov 2008 11:06:28 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John C Klensin <[e-mail]> writes:

> Folks,
>
> While I have no particular attachment to CRAM-MD5 -- Paul,
> Randy, and I created it as a service to the community -- I
> suggest that you consider this active _very_ carefully.

The WG has discussed this particular issue for several IETF meetings
now.  It seems difficult to come to consensus around the issue.

> Given all of that, I wonder if denouncing CRAM-MD5 as strongly
> as this document seems to is really appropriate.  Would it not
> be a lot more sensible and realistic to:
>
> 	(i) Publish an updated version of 2195 that reflects at
> 	more length on the security issues and warnings about
> 	them?  I note that, given the requirement for two
> 	interoperable implementations, this document could be
> 	published at Draft Standard and that there is _no_ bar
> 	to doing so under the procedures specified in RFC 2026.

I would support this path, and given the deployment believe it makes
some sense to do this, but others (Sam?) have said they would not
support a backwards compatible CRAM-MD5 on the standards track.

> 	(ii) Publish SCRAM and see if it gets any traction in
> 	practice.

+1.

/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 mAPMbT7i089802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 15:37:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPMbTeC089801; Tue, 25 Nov 2008 15:37:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPMbR51089795 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 15:37:28 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L56X6-0000B7-Fa; Tue, 25 Nov 2008 23:37:25 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
References: <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[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:081125:[e-mail]::ZAKy7CpkRj2BHP+Z:09+i
X-Hashcash: 1:22:081125:[e-mail]::aSgku6JJcF1WWifA:BDWy
X-Hashcash: 1:22:081125:[e-mail]::/+sc7vF9Bk+YHBbb:KrwT
X-Hashcash: 1:22:081125:[e-mail]::yRmckTPGzzTMSIvP:EC3+
Date: Tue, 25 Nov 2008 23:37:23 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 25 Nov 2008 16:08:06 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Nov 25, 2008 at 10:46:19PM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > What we could do, however, is assign non-hash-derived SASL/GS2 mech
>> > names to SCRAM and Kerberos V from the get-go, and use hash-derived
>> > SASL/GS2 mech names for all other GSS mechs.  Just like SASL/GS1 did,
>> > effectively.
>> 
>> Ok.  Then I don't think an IANA registry will work: how will you handle
>> negotiation of a future GSS-API mechanism X?  It won't be mentioned in
>
> You misunderstood.  I was saying what you say in option (2) below.

Okay, but my 2) does not involve an IANA registry, and my point was that
an IANA registry for the names that would need to be mentioned
explicitly in GS2 does not work due to the future-mechanism negotiation
problem.

I think an IANA registry is only useful (and even compatible) together
with 1).

>> I guess the options are:
>> 
>> 1) Never use hash-derived mech names.  Instead require that a SASL name
>> is registered for every GSS-API mechanism OID.
>> 
>> 2) Use hash-derived mech names for "other" GSS-API mechanisms, but
>> mention the exceptions of SCRAM and KRBV5 in the GS2 document.
>> 
>> 3) Always use hash-derived mech names.
>
>> Frankly, I don't see the benefit of 2).  It has all the complexity of
>> BOTH solutions and I don't see any advantages.
>
> It'd make SCRAM more palatable to pure SASL implementors, I suspect.

They aren't likely to use KRBV5, so let's reduce the list of explicit
mech's to mention explicitly to only SCRAM then.  If even that is
needed.

/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 mAPMGVWw089028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 15:16:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPMGViH089027; Tue, 25 Nov 2008 15:16:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 mAPMGKvo089015 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 15:16:30 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAPMGJeq014858 for <[e-mail]>; Tue, 25 Nov 2008 22:16:20 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAPMGJJ2000257 for <[e-mail]>; Tue, 25 Nov 2008 15:16:19 -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 mAPM876W019198; Tue, 25 Nov 2008 16:08:07 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPM866x019197; Tue, 25 Nov 2008 16:08:06 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 16:08:06 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Message-ID: <[e-mail]>
References: <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 25, 2008 at 10:46:19PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > What we could do, however, is assign non-hash-derived SASL/GS2 mech
> > names to SCRAM and Kerberos V from the get-go, and use hash-derived
> > SASL/GS2 mech names for all other GSS mechs.  Just like SASL/GS1 did,
> > effectively.
> 
> Ok.  Then I don't think an IANA registry will work: how will you handle
> negotiation of a future GSS-API mechanism X?  It won't be mentioned in

You misunderstood.  I was saying what you say in option (2) below.

> I guess the options are:
> 
> 1) Never use hash-derived mech names.  Instead require that a SASL name
> is registered for every GSS-API mechanism OID.
> 
> 2) Use hash-derived mech names for "other" GSS-API mechanisms, but
> mention the exceptions of SCRAM and KRBV5 in the GS2 document.
> 
> 3) Always use hash-derived mech names.

> Frankly, I don't see the benefit of 2).  It has all the complexity of
> BOTH solutions and I don't see any advantages.

It'd make SCRAM more palatable to pure SASL implementors, I suspect.

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 mAPMAKel088598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 15:10:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPMAKl8088597; Tue, 25 Nov 2008 15:10:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPMA849088542 for <[e-mail]>; Tue, 25 Nov 2008 15:10:19 -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 945C24AC4B; Tue, 25 Nov 2008 23:10:07 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.4) with esmtp id 1227651007-55372-1/6/15 for [e-mail]; Tue, 25 Nov 2008 23:10:07 +0100
Message-Id: <[e-mail]>
Date: Tue, 25 Nov 2008 23:09:17 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
References: <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What are some applications that implement their own SASL framework, 
would need updates to support new SASL mechanisms, and would NOT need 
updates to support new SASL/GS2 mechanisms?

Anrt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPLkQeW087312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 14:46:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPLkQM3087311; Tue, 25 Nov 2008 14:46: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 mAPLkNHf087305 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 14:46:25 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L55jg-00009t-Ee; Tue, 25 Nov 2008 22:46:21 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
References: <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[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:081125:[e-mail]::ehzkjQPHyjWVc8Vn:TOr
X-Hashcash: 1:22:081125:[e-mail]::V0qDMsbiWOUB1mwa:20/i
X-Hashcash: 1:22:081125:[e-mail]::kEfZIrmKx/vIF5bk:LR73
X-Hashcash: 1:22:081125:[e-mail]::8jGEjrMsLWoPO3jt:X+tk
Date: Tue, 25 Nov 2008 22:46:19 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 25 Nov 2008 15:23:55 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Nov 25, 2008 at 10:09:32PM +0100, Simon Josefsson wrote:
>> I'll prepare text to achieve this in the GS2 document.  It will require
>> some additional IANA considerations, but that shouldn't be too onerous.
>
> Wait.
>
> Sam has an objection to not deriving SASL/GS2 mech names from the OID of
> the GSS mech.
>
> Sam argues that that change would require updating SASL frameworks when
> new GSS mechs become available.  And he's right.
>
> Of course, for an operating system vendor/distro the preferred retort to
> that would be that packages delivering GSS mechanism plug-ins should
> update both, the gss mechglue and the sasl mechglue.
>
> But that's not enough.  There's no reason that a third party couldn't
> develop an application that implements its own SASL client framework,
> say, and there exist apps that do just that.  Such apps would have to be
> updated manually.  And that's not acceptable.
>
> What we could do, however, is assign non-hash-derived SASL/GS2 mech
> names to SCRAM and Kerberos V from the get-go, and use hash-derived
> SASL/GS2 mech names for all other GSS mechs.  Just like SASL/GS1 did,
> effectively.

Ok.  Then I don't think an IANA registry will work: how will you handle
negotiation of a future GSS-API mechanism X?  It won't be mentioned in
the GS2 document, so an initial GS2 implementation would not be aware of
it, and thus will use the hash-derived mech name.  If there is an IANA
registry, and some other GS2 implementation comes along that knows about
the SASL mech name registered for X, it won't interoperate with the
other GS2 implementation.

I guess the options are:

1) Never use hash-derived mech names.  Instead require that a SASL name
is registered for every GSS-API mechanism OID.

2) Use hash-derived mech names for "other" GSS-API mechanisms, but
mention the exceptions of SCRAM and KRBV5 in the GS2 document.

3) Always use hash-derived mech names.

Frankly, I don't see the benefit of 2).  It has all the complexity of
BOTH solutions and I don't see any advantages.

Well, ok, one minor advantage with 2) is that you will save 10-15 bytes
or so on the initial context token.  But bandwidth optimization doesn't
warrant complexity of this magnitude without benchmarks illustrating
bandwidth usage is the bottle-neck, in my opinion.

/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 mAPLWciM086407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 14:32:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPLWcY9086406; Tue, 25 Nov 2008 14:32:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPLWSlo086388 for <[e-mail]>; Tue, 25 Nov 2008 14:32:38 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAPLWRL3019824 for <[e-mail]>; Tue, 25 Nov 2008 21:32: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 mAPLWRFY019296 for <[e-mail]>; Tue, 25 Nov 2008 14:32:27 -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 mAPLOAsv019161; Tue, 25 Nov 2008 15:24:10 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPLNtMi019160; Tue, 25 Nov 2008 15:23:55 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 15:23:55 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[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, Nov 25, 2008 at 10:09:32PM +0100, Simon Josefsson wrote:
> I'll prepare text to achieve this in the GS2 document.  It will require
> some additional IANA considerations, but that shouldn't be too onerous.

Wait.

Sam has an objection to not deriving SASL/GS2 mech names from the OID of
the GSS mech.

Sam argues that that change would require updating SASL frameworks when
new GSS mechs become available.  And he's right.

Of course, for an operating system vendor/distro the preferred retort to
that would be that packages delivering GSS mechanism plug-ins should
update both, the gss mechglue and the sasl mechglue.

But that's not enough.  There's no reason that a third party couldn't
develop an application that implements its own SASL client framework,
say, and there exist apps that do just that.  Such apps would have to be
updated manually.  And that's not acceptable.

What we could do, however, is assign non-hash-derived SASL/GS2 mech
names to SCRAM and Kerberos V from the get-go, and use hash-derived
SASL/GS2 mech names for all other GSS mechs.  Just like SASL/GS1 did,
effectively.

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 mAPL9rgV084804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 14:09:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPL9ru8084803; Tue, 25 Nov 2008 14:09:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPL9fQP084783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 14:09:53 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L55A5-000098-RO; Tue, 25 Nov 2008 22:09:38 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081125:[e-mail]::QneSlTlLFBHBxwJu:Qm+
X-Hashcash: 1:22:081125:[e-mail]::iy6IU8j3PH1Af187:5B93
X-Hashcash: 1:22:081125:[e-mail]::Wjm7PT7rlHUw7NcA:97wM
X-Hashcash: 1:22:081125:[e-mail]::FPbxOoz/AfgbZ1y8:7zV9
Date: Tue, 25 Nov 2008 22:09:32 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 25 Nov 2008 10:01:34 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Nov 25, 2008 at 04:56:58PM +0100, Simon Josefsson wrote:
>> Ah.  Good idea, I had either forgotten about it or never heard of it.  I
>> believe GS2 needs to add some text about this naming truncation.  The
>> majority of the text that defines SCRAM as a GSS-API mechanism should
>> likely go into the SCRAM document though.
>
> Glad you like it.  At first Sam and I thought it was a fairly radical
> idea, but it grows on me, you don't object, and I doubt any of the
> SCRAM-as-pure-SASL-mech implementors would object (as if!).  It's simple
> enough and not really costly in terms of code for SCRAM-as-SASL/GS2
> implementors, so let's do it.
>
> Yes, much, if not all of the text that describes SCRAM-as-a-GSS-API-mech
> should be in the main SCRAM doc.

I'll prepare text to achieve this in the GS2 document.  It will require
some additional IANA considerations, but that shouldn't be too onerous.

/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 mAPGMTvb066551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 09:22:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPGMTqg066550; Tue, 25 Nov 2008 09:22:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPGMJen066542 for <[e-mail]>; Tue, 25 Nov 2008 09:22:29 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAPGMID8002475 for <[e-mail]>; Tue, 25 Nov 2008 16:22:18 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAPGMI9H001019 for <[e-mail]>; Tue, 25 Nov 2008 09:22:18 -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 mAPGE5rL018953; Tue, 25 Nov 2008 10:14:05 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPGE4x6018952; Tue, 25 Nov 2008 10:14:04 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 10:14:04 -0600
From: Nicolas Williams <[e-mail]>
To: Tom Yu <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 25, 2008 at 10:59:25AM -0500, Tom Yu wrote:
> Are you suggesting abandoning the OID-hash-based mech names for GS2 SASL
> mechs?

I am.  I see that Simon likes that, and I suspect that Chris would be
ecstatic.

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 mAPGLWvU066491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 09:21:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPGLWC2066490; Tue, 25 Nov 2008 09:21:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-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 mAPGLLeS066475 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 09:21:31 -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 mAPGLKrA001645 for <[e-mail]>; Tue, 25 Nov 2008 16:21:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAPGLKtg063948 for <[e-mail]>; Tue, 25 Nov 2008 09:21:20 -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 mAPGD6wi018946; Tue, 25 Nov 2008 10:13:06 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPGD6sn018945; Tue, 25 Nov 2008 10:13:06 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 10:13:06 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 25, 2008 at 05:03:59PM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > But we'd have so few exceptions that we might as well:
> >
> > a) list them all now for all known GSS mechs
> > b) create a registry or expand the existing IANA SASL mech name registry
> >
> > I don't think that'd suck, so why not?
> 
> I think it depends on whether we want to abandon the GS2-* naming scheme
> altogether, and instead make the IANA SASL registry contain three
> columns:

I am not a fan of hashing OIDs to make SASL mech names.

> SASL mechanism name     Optional GSS-API mechanism OID    Reference
> 
> CRAM-MD5                                                  RFC 2095
> SCRAM-HMAC-SHA-1        1.3.6.1.4.1.11591.4.2             RFC X
> ...

Yes.

> Then you need to register a SASL mechanism name for every GSS-API
> mechanism you want to use in SASL via GS2 explicitly.

Yes.  Registration rules should be light-weight.

> GS2 would then be responsible for adding/removing the GSS-API specific
> OID-prefix in the first context token.  If a GS2 implementation does not
> know how to map between a particular OID and a SASL mech name, it gives
> up.

Right.

> I would prefer this approach.  I think the B32(TRUNC(SHA1(DER(OID))))
> approach is complex and ugly.

Me too.

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 mAPG9nOJ065641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 09:09:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPG9nwg065640; Tue, 25 Nov 2008 09:09:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 mAPG9nlm065633 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 09:09:49 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAPG9m64028993 for <[e-mail]>; Tue, 25 Nov 2008 16:09:48 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAPG9maR041497 for <[e-mail]>; Tue, 25 Nov 2008 09:09: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 mAPG1YA4018926; Tue, 25 Nov 2008 10:01:34 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPG1YwA018925; Tue, 25 Nov 2008 10:01:34 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 10:01:34 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 25, 2008 at 04:56:58PM +0100, Simon Josefsson wrote:
> Ah.  Good idea, I had either forgotten about it or never heard of it.  I
> believe GS2 needs to add some text about this naming truncation.  The
> majority of the text that defines SCRAM as a GSS-API mechanism should
> likely go into the SCRAM document though.

Glad you like it.  At first Sam and I thought it was a fairly radical
idea, but it grows on me, you don't object, and I doubt any of the
SCRAM-as-pure-SASL-mech implementors would object (as if!).  It's simple
enough and not really costly in terms of code for SCRAM-as-SASL/GS2
implementors, so let's do it.

Yes, much, if not all of the text that describes SCRAM-as-a-GSS-API-mech
should be in the main SCRAM doc.

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 mAPG6n1x065413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 09:06:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPG6nB8065412; Tue, 25 Nov 2008 09:06:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPG6b6Z065394 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 09:06:48 -0700 (MST) (envelope-from [e-mail])
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L50Qo-000C1Y-06; Tue, 25 Nov 2008 11:06:30 -0500
Date: Tue, 25 Nov 2008 11:06:28 -0500
From: John C Klensin <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Monday, 24 November, 2008 14:30 -0800
[e-mail] wrote:

> A New Internet-Draft is available from the on-line
> Internet-Drafts  directories.
> This draft is a work item of the Simple Authentication and
> Security Layer Working Group of the IETF.
> 
> 	Title		: CRAM-MD5 to Historic
> 	Author(s)	: K. Zeilenga
> 	Filename	: draft-ietf-sasl-crammd5-to-historic-00.txt
> 	Pages		: 6
> 	Date		: 2008-11-24
> 	
> This document recommends the retirement of the CRAM-MD5
> authentication   mechanism, and discusses the reasons for
> doing so.  This document   recommends RFC 2195 and its
> predecessor, RFC 2095, be moved to   Historic status.

Folks,

While I have no particular attachment to CRAM-MD5 -- Paul,
Randy, and I created it as a service to the community -- I
suggest that you consider this active _very_ carefully.   In
particular (and playing the role of devil's advocate much more
than that of author):

* CRAM-MD5 was designed at a time when the IETF was campaigning
against clear-text passwords on the wire, as a "better than
nothing" alternative.  While its perceived strength has weakened
over the years, it may still have some value in that area.
More important, it did not require cryptography, which was
perceived as an important issue for places and circumstances
where cryptography was prohibited or significantly restricted.

* Empirically, CRAM-MD5 is quite widely deployed and
interoperable.  The claims in this document about the weakness
of the definition notwithstanding, the evidence on the ground is
that people have been able to make it work (possibly by
aggressive application of the robustness principle).  Replacing
it on a flag-day basis ("move this to Historic when SCRAM is
published") with a protocol that has not been similarly tested
and deployed seems to me to be unwise.

* The document appears to suggest that clear-text passwords over
TLS are more desirable than CRAM-MD5.   In a world in which

	 (i) all certificates were anchored in well-established
	and trustworthy CAs and based on more than "responds to
	email" or "has domain" and
	
	 (ii) an in-depth analysis had been done on the ability
	to use partially-known-plaintext attacks (based on the
	very predictable nature of the SMTP, POP, IMAP, etc.,
	session-initiation dialogues) on TLS and a conclusion of
	"no problems" reached

I would certainly agree with that conclusion about clear-text
over TLS if it were substantiated.  However, in a world in which
typical certs for mail servers seem to be either self-signed (or
certified on the basis of email address dialogues or domain name
ownership), in which attacks on the DNS are well-known and the
proper response to "Bind 8 is dead" may be "before or after Bind
4?", methods based on challenge-response may have one advantage
that the I-D does not discuss, namely being independent of the
certificate and DNS situation and relationships.  


* The previous effort to replace CRAM-MD5 with something else
involved an effort to deprecate it in favor of Digest-MD5 which
was argued to be much more secure, etc., etc.   That effort
fizzled out when it became clear that Digest-MD5 had its own set
of problems and that the marginal security benefits were
probably not worth the trouble.  I have not studied SCRAM, but,
absent an RFC-published specification and several years of
experience, I don't have significant reason to believe that, in
practice, it will offer much more marginal benefit over CRAM-MD5
than Digest-MD5 turned out to.   Trying to replace one mechanism
with another involves significant costs, especially to
interoperability as some systems select one of the methods and
others select other ones, so the advantages had better be
significant.

Given all of that, I wonder if denouncing CRAM-MD5 as strongly
as this document seems to is really appropriate.  Would it not
be a lot more sensible and realistic to:

	(i) Publish an updated version of 2195 that reflects at
	more length on the security issues and warnings about
	them?  I note that, given the requirement for two
	interoperable implementations, this document could be
	published at Draft Standard and that there is _no_ bar
	to doing so under the procedures specified in RFC 2026.
	
	(ii) Publish SCRAM and see if it gets any traction in
	practice.
	
	(iii) When, and only if, SCRAM actually does get
	significant deployment in practice, move CRAM-MD5 to
	Historic.

regards,
    john





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPG6EYi065376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 09:06:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPG6EQP065375; Tue, 25 Nov 2008 09:06:14 -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 mAPG626w065356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 09:06:13 -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 mAPG5M9v002960; Tue, 25 Nov 2008 11:05:56 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mAPFxQbP016782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Nov 2008 10:59:26 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mAPFxP8t025265; Tue, 25 Nov 2008 10:59:26 -0500 (EST)
To: Nicolas Williams <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Tue, 25 Nov 2008 10:59:25 -0500
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 25 Nov 2008 09:26:58 -0600")
Message-ID: <[e-mail]>
Lines: 26
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>

Nicolas Williams <[e-mail]> writes:

> On Tue, Nov 25, 2008 at 11:05:51AM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > Incidentally, there is the possibility of SASL/GS2 using names not
>> > derived from hashing GSS mech OIDs, instead requiring registration
>> > first.  I don't mind that, but it seems less flexible.
>> 
>> Good point.  If we, for some reason, want to retain the SCRAM-HMAC-SHA-1
>> SASL mech name even when SCRAM happens to be implemented as a GSS-API
>> mechanism, and supported in SASL via GS2, we could add an exception in
>> the GS2 document such as this:
>> 
>>   GS2 implementations MUST use the SCRAM-HMAC-SHA-1 mechanism name for
>>   the GSS-API mechanism with OID 1.3.6.1.4.1.11591.4.2.
>
> But we'd have so few exceptions that we might as well:
>
> a) list them all now for all known GSS mechs
> b) create a registry or expand the existing IANA SASL mech name registry
>
> I don't think that'd suck, so why not?

Are you suggesting abandoning the OID-hash-based mech names for GS2 SASL
mechs?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPG43Pi065216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 09:04:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPG43Pn065215; Tue, 25 Nov 2008 09:04:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPG419P065208 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 09:04:02 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L50OO-00005o-0q; Tue, 25 Nov 2008 17:04:00 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081125:[e-mail]::YOXBi9Jneop2MrPW:ABZ6
X-Hashcash: 1:22:081125:[e-mail]::eONuXMY9IU93s2EF:6Y/9
X-Hashcash: 1:22:081125:[e-mail]::0UrwQjfkaIhuVmrG:c2Nh
Date: Tue, 25 Nov 2008 17:03:59 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 25 Nov 2008 09:26:58 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Nov 25, 2008 at 11:05:51AM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > Incidentally, there is the possibility of SASL/GS2 using names not
>> > derived from hashing GSS mech OIDs, instead requiring registration
>> > first.  I don't mind that, but it seems less flexible.
>> 
>> Good point.  If we, for some reason, want to retain the SCRAM-HMAC-SHA-1
>> SASL mech name even when SCRAM happens to be implemented as a GSS-API
>> mechanism, and supported in SASL via GS2, we could add an exception in
>> the GS2 document such as this:
>> 
>>   GS2 implementations MUST use the SCRAM-HMAC-SHA-1 mechanism name for
>>   the GSS-API mechanism with OID 1.3.6.1.4.1.11591.4.2.
>
> But we'd have so few exceptions that we might as well:
>
> a) list them all now for all known GSS mechs
> b) create a registry or expand the existing IANA SASL mech name registry
>
> I don't think that'd suck, so why not?

I think it depends on whether we want to abandon the GS2-* naming scheme
altogether, and instead make the IANA SASL registry contain three
columns:

SASL mechanism name     Optional GSS-API mechanism OID    Reference

CRAM-MD5                                                  RFC 2095
SCRAM-HMAC-SHA-1        1.3.6.1.4.1.11591.4.2             RFC X
...

Then you need to register a SASL mechanism name for every GSS-API
mechanism you want to use in SASL via GS2 explicitly.

GS2 would then be responsible for adding/removing the GSS-API specific
OID-prefix in the first context token.  If a GS2 implementation does not
know how to map between a particular OID and a SASL mech name, it gives
up.

I would prefer this approach.  I think the B32(TRUNC(SHA1(DER(OID))))
approach is complex and ugly.

/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 mAPFvEnR064647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 08:57:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPFvE2u064646; Tue, 25 Nov 2008 08:57: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 mAPFv26n064615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 08:57:14 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L50Hb-00005a-2q; Tue, 25 Nov 2008 16:56:59 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GSS init tok header compression (Re: SCRAM and mechanism family)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081125:[e-mail]::aoUUa1z9cS0za2in:1Clo
X-Hashcash: 1:22:081125:[e-mail]::3d9HmVZLQbhIsbe6:7nu7
X-Hashcash: 1:22:081125:[e-mail]::jE+FAQwtb0kobJFM:B6yU
X-Hashcash: 1:22:081125:[e-mail]::T/xC6/8NiolccuP5:bslt
Date: Tue, 25 Nov 2008 16:56:58 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 25 Nov 2008 09:21:46 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, Nov 25, 2008 at 11:01:50AM +0100, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > On Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
>> >> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[e-mail]> 
>> >> wrote:
>> >> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
>> >> >minimal: just the OID-prefix on the first message.  And a section
>> >> >describing the GSS-API related semantics (prot-ready etc).
>> >
>> > Only if we go with compression of that OID (which we should), though the
>> > change then is slightly more involved, IIRC, but still in the realm of
>> > the trivial.
>> 
>> What do you mean by OID compression?
>
> Sam and I came up with an OID compression scheme for SASL/GS2 quite a
> while ago as a way to make sure that implementors of SCRAM-as-a-pure-
> SASL mech don't have to put on the wire that pseudo-ASN.1 header from
> RFC2743 on initial context tokens.  I thought we'd discussed it on the
> list and/or at IETF meetings.
>
> Basically: you know the OID from the SASL mech name so there's no need
> to put in that header.
>
> A SASL/GS2 client implementation based on the GSS-API can recognize and
> remove that header trivially.  (The code to do this exists in most every
> GSS-API mechglue implementation, of which there are several open-source
> ones.)
>
> A SASL/GS2 server implementation based on the GSS-API will be able to
> recover the OID from the SASL mech name (yes, the SASL mech name results
> from applying a one way function to the mech's GSS OID, but there's a
> very small set of GSS mech OIDs) and so will be able to re-create that
> header prior to calling GSS_Accept_sec_context().  (The code to
> create that headerexists in most every GSS-API mechglue implementation,
> ...)

Ah.  Good idea, I had either forgotten about it or never heard of it.  I
believe GS2 needs to add some text about this naming truncation.  The
majority of the text that defines SCRAM as a GSS-API mechanism should
likely go into the SCRAM document though.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPFZkdj062407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 08:35:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPFZkPB062406; Tue, 25 Nov 2008 08:35:46 -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 mAPFZNbX062373 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 08:35:33 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAPFZCva019023 for <[e-mail]>; Tue, 25 Nov 2008 15:35:22 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 mAPFZCnJ001965 for <[e-mail]>; Tue, 25 Nov 2008 08:35:12 -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 mAPFQwXT018898; Tue, 25 Nov 2008 09:26:58 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPFQwSj018897; Tue, 25 Nov 2008 09:26:58 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 09:26:58 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
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, Nov 25, 2008 at 11:05:51AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > Incidentally, there is the possibility of SASL/GS2 using names not
> > derived from hashing GSS mech OIDs, instead requiring registration
> > first.  I don't mind that, but it seems less flexible.
> 
> Good point.  If we, for some reason, want to retain the SCRAM-HMAC-SHA-1
> SASL mech name even when SCRAM happens to be implemented as a GSS-API
> mechanism, and supported in SASL via GS2, we could add an exception in
> the GS2 document such as this:
> 
>   GS2 implementations MUST use the SCRAM-HMAC-SHA-1 mechanism name for
>   the GSS-API mechanism with OID 1.3.6.1.4.1.11591.4.2.

But we'd have so few exceptions that we might as well:

a) list them all now for all known GSS mechs
b) create a registry or expand the existing IANA SASL mech name registry

I don't think that'd suck, so why not?

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 mAPFUnQw061866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 08:30:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPFUnrg061865; Tue, 25 Nov 2008 08:30:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPFUboN061845 for <[e-mail]>; Tue, 25 Nov 2008 08:30:47 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAPFUam4005688 for <[e-mail]>; Tue, 25 Nov 2008 15:30:36 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 mAPFUaBu061623 for <[e-mail]>; Tue, 25 Nov 2008 08:30:36 -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 mAPFMFhV018892; Tue, 25 Nov 2008 09:22:20 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAPFLkXl018891; Tue, 25 Nov 2008 09:21:46 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 25 Nov 2008 09:21:46 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: GSS init tok header compression (Re: SCRAM and mechanism family)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 25, 2008 at 11:01:50AM +0100, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > On Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
> >> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[e-mail]> 
> >> wrote:
> >> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
> >> >minimal: just the OID-prefix on the first message.  And a section
> >> >describing the GSS-API related semantics (prot-ready etc).
> >
> > Only if we go with compression of that OID (which we should), though the
> > change then is slightly more involved, IIRC, but still in the realm of
> > the trivial.
> 
> What do you mean by OID compression?

Sam and I came up with an OID compression scheme for SASL/GS2 quite a
while ago as a way to make sure that implementors of SCRAM-as-a-pure-
SASL mech don't have to put on the wire that pseudo-ASN.1 header from
RFC2743 on initial context tokens.  I thought we'd discussed it on the
list and/or at IETF meetings.

Basically: you know the OID from the SASL mech name so there's no need
to put in that header.

A SASL/GS2 client implementation based on the GSS-API can recognize and
remove that header trivially.  (The code to do this exists in most every
GSS-API mechglue implementation, of which there are several open-source
ones.)

A SASL/GS2 server implementation based on the GSS-API will be able to
recover the OID from the SASL mech name (yes, the SASL mech name results
from applying a one way function to the mech's GSS OID, but there's a
very small set of GSS mech OIDs) and so will be able to re-create that
header prior to calling GSS_Accept_sec_context().  (The code to
create that headerexists in most every GSS-API mechglue implementation,
...)

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 mAPA5vMA026521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 03:05:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPA5vsl026520; Tue, 25 Nov 2008 03:05:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAPA5sIh026477 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 03:05:55 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L4unp-0008Fj-61; Tue, 25 Nov 2008 11:05:53 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
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:081125:[e-mail]::dguK6AtDuN1n3vu2:1Id5
X-Hashcash: 1:22:081125:[e-mail]::Mo7U15twtmhTDlNq:J3KM
X-Hashcash: 1:22:081125:[e-mail]::zvBjYVrTfUmZq380:xB+v
Date: Tue, 25 Nov 2008 11:05:51 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 24 Nov 2008 13:08:14 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> Incidentally, there is the possibility of SASL/GS2 using names not
> derived from hashing GSS mech OIDs, instead requiring registration
> first.  I don't mind that, but it seems less flexible.

Good point.  If we, for some reason, want to retain the SCRAM-HMAC-SHA-1
SASL mech name even when SCRAM happens to be implemented as a GSS-API
mechanism, and supported in SASL via GS2, we could add an exception in
the GS2 document such as this:

  GS2 implementations MUST use the SCRAM-HMAC-SHA-1 mechanism name for
  the GSS-API mechanism with OID 1.3.6.1.4.1.11591.4.2.

/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 mAPA2I30026058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 03:02:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAPA2Ic2026053; Tue, 25 Nov 2008 03:02:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 mAPA22cn026028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Nov 2008 03:02:16 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L4ujy-0008FV-Uw; Tue, 25 Nov 2008 11:01:55 +0100
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Chris Newman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081125:[e-mail]::72/gVpfgo5N2Dql7:3dk
X-Hashcash: 1:22:081125:[e-mail]::k2GQgzVnfmpWjBr9:2w5W
X-Hashcash: 1:22:081125:[e-mail]::iE0Gyj4+c4IEWyfu:224l
X-Hashcash: 1:22:081125:[e-mail]::XaU/2WdZpkkTNQ3+:2Lt/
Date: Tue, 25 Nov 2008 11:01:50 +0100
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 24 Nov 2008 13:05:40 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
>> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[e-mail]> 
>> wrote:
>> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
>> >minimal: just the OID-prefix on the first message.  And a section
>> >describing the GSS-API related semantics (prot-ready etc).
>
> Only if we go with compression of that OID (which we should), though the
> change then is slightly more involved, IIRC, but still in the realm of
> the trivial.

What do you mean by OID compression?

> As for implementations, the more significant are the changes to go from
> meeting whatever requirements of a SASL implementation's plug-in SPI to
> meeting the requirements of a GSS-API implementation's plug-in SPI, plus
> -optionally- providing a true SASL/GS2 implementation.

Agreed, this will be the challenge.  I believe it is likely that
implementation feedback will result in some specification changes or new
specification further down the road.

/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 mAOMU0ZI088472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 15:30:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOMU02S088471; Mon, 24 Nov 2008 15:30:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOMU0ZX088454 for <[e-mail]>; Mon, 24 Nov 2008 15:30:00 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id B88703A682C; Mon, 24 Nov 2008 14:30:01 -0800 (PST)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 24 Nov 2008 14:30:01 -0800 (PST)
Sender: [e-mail]
Precedence: 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		: CRAM-MD5 to Historic
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-crammd5-to-historic-00.txt
	Pages		: 6
	Date		: 2008-11-24
	
This document recommends the retirement of the CRAM-MD5 authentication
  mechanism, and discusses the reasons for doing so.  This document
  recommends RFC 2195 and its predecessor, RFC 2095, be moved to
  Historic status.


  [[Note to RFC Editor: please publish at same time that [SCRAM] is
  published.]]



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-crammd5-to-historic-00.txt

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOKOjR5072873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 13:24:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOKOjbP072872; Mon, 24 Nov 2008 13:24:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOKOjCF072864 for <[e-mail]>; Mon, 24 Nov 2008 13:24:45 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOKOiJu002112 for <[e-mail]>; Mon, 24 Nov 2008 20:24:44 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAOKOiRM038611 for <[e-mail]>; Mon, 24 Nov 2008 13:24: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 mAOKGWvU018201; Mon, 24 Nov 2008 14:16:32 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAOKGVWK018200; Mon, 24 Nov 2008 14:16:31 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 24 Nov 2008 14:16:31 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Nov 20, 2008 at 08:00:22AM -0600, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >I brought this up on the jabber chat during the WG presentation of
> >SCRAM, but it may be useful to repeat here to get feedback.
> >
> >Why does SCRAM needs to be defined as a mechanism family?
> 
> It doesn't have to. But the document already defines any SCRAM mechanism 
> as if the hash function is pluggable. I personally like it like that and 
> I don't see a reason to change the document.

I see Simon's issue as one bearing on: a) implementation details of
pluggable SASL frameworks, b) how easy it is to create variants of SCRAM
(just an IANA registration?  or a new RFC?).

With regard to (b), for variants of SCRAM differing from the original
SCRAM only in terms of which cryptographic algorithms are used, sure, an
IANA registration might be sufficient, while still allowing
registration-via-RFC- publication for variants that differ more
significantly.

As to (a), what component should be aware of and implement the
cryptographic algorithm pluggability of a mechanism family?  The SASL
mechglue?  Or the mechanism plug-ins to that mechglue?

I believe that question answers itself.  It should be the mechanism.  I
think it's possible that the SCRAM spec's wording might lead an
implementor astray, so it's worth discussing this implementation design
detail.

Think of a framework with a config file, say, /etc/sasl/mechs, which
lists {<mech-name>, <plug-in-object>}, with one plug-in object that
implements all variants of SCRAM.  As long as the plug-in interfaces
allow the plug-in to know the name of the mechanism it is implementing
at any given time then a signle object can very well implement all
variants of SCRAM.

An alternative design that makes the framework implement SCRAM's
pluggability might look like this: a config file, say, /etc/sasl/mech,
that lists {<mech-name>, <plug-in-object>, <algorithm-options>}, where
the mechglue passes the plug-in object a set of function/class/whatever
for the <algorithm-options> references instead of the <mech-name>.  Such
a design would clearly limit a plug-in implementor's freedom to
implement variants of SCRAM with a single plug-in object should a future
variant of SCRAM differ from today's in more ways than just which hash
function algorithm it uses.

As I said, I think the first implementation design is obviously the
better one.

The spec should not be written such that a SASL framework implementor
could be misled into thinking that the second design is the correct one.
Referring to SCRAM as a "mechanism family" might just do that.  But in
practice I doubt 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 mAOKAJPA070586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 13:10:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOKAJAA070585; Mon, 24 Nov 2008 13:10:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAOKA8D7070544 for <[e-mail]>; Mon, 24 Nov 2008 13:10:18 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAOKA8dS021780 for <[e-mail]>; Mon, 24 Nov 2008 20:10:08 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 mAOKA7dg020624 for <[e-mail]>; Mon, 24 Nov 2008 13:10:07 -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 mAOK1tBG018193; Mon, 24 Nov 2008 14:01:55 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAOK1tJF018192; Mon, 24 Nov 2008 14:01:55 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 24 Nov 2008 14:01:55 -0600
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM and mechanism family
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Nov 20, 2008 at 01:03:06PM +0100, Simon Josefsson wrote:
> I brought this up on the jabber chat during the WG presentation of
> SCRAM, but it may be useful to repeat here to get feedback.
> 
> Why does SCRAM needs to be defined as a mechanism family?

It doesn't have to be.  In fact, it shouldn't be in that a SASL mechglue
implementation should not be aware of it, even though the implementation
of the SCRAM mechanisms may well share so much common code as to be make
it a "mechanism family."

I.e., the "family" thing should be an implementation detail, not a
detail that binds us to today's SCRAM design when we go add a new hash
tomorrow.

> If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
> obvious reason for defining SCRAM as a family, taking the current SCRAM
> document and replacing SHA-1 with SHA-256 is possible.

No need to copy the doc, just have a new one with a normative reference
to the old one, with the new one saying "use the new OID/name and
SHA-256 instead of SHA-1."

> The non-family approach has the benefit of making it simple to introduce
> improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
> necessary.

Absolutely.

> I think SASL mechanism families introduce complexity for little gain,
> but I'd be interested to understand why it was added here.

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 mAOJGc93062729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 12:16:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOJGchH062728; Mon, 24 Nov 2008 12:16:38 -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 mAOJGRXA062695 for <[e-mail]>; Mon, 24 Nov 2008 12:16:38 -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 mAOJGRrc017843 for <[e-mail]>; Mon, 24 Nov 2008 19:16:27 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 mAOJGRPv062399 for <[e-mail]>; Mon, 24 Nov 2008 12:16:27 -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 mAOJ8EgN017555; Mon, 24 Nov 2008 13:08:14 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAOJ8EIY017554; Mon, 24 Nov 2008 13:08:14 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 24 Nov 2008 13:08:14 -0600
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Nov 20, 2008 at 04:24:21PM -0600, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >Alexey Melnikov <[e-mail]> writes:
> >>I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1
> >>with IANA.
> >>   
> >>
> >It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
> >and supported in SASL via GS2, the mechanism name registered with IANA
> >will be the GS2-* name, not SCRAM-HMAC-SHA-1.
> >
> That is correct.
> But I wanted to resolve all outstanding issues except for GS2 framing 
> and make the document self consistent.

I'm confused.  How does registering "SCRAM-HMAC-SHA-1" help with that?

Incidentally, there is the possibility of SASL/GS2 using names not
derived from hashing GSS mech OIDs, instead requiring registration
first.  I don't mind that, but it seems less flexible.

> >Have we given up on supporting SCRAM as a GSS-API mechanism?
> >
> No.

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 mAOJEYbw062609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 12:14:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOJEYh2062608; Mon, 24 Nov 2008 12:14:34 -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 mAOJEM1b062595 for <[e-mail]>; Mon, 24 Nov 2008 12:14:32 -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 mAOJELa0006108 for <[e-mail]>; Mon, 24 Nov 2008 19:14:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAOJEL1p060280 for <[e-mail]>; Mon, 24 Nov 2008 12:14:21 -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 mAOJ68jX017549; Mon, 24 Nov 2008 13:06:08 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mAOJ5etQ017548; Mon, 24 Nov 2008 13:05:40 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 24 Nov 2008 13:05:40 -0600
From: Nicolas Williams <[e-mail]>
To: Chris Newman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0EBD68AA064ADB40A0591FCD@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 Fri, Nov 21, 2008 at 06:06:10PM -0600, Chris Newman wrote:
> --On November 20, 2008 22:33:00 +0100 Simon Josefsson <[e-mail]> 
> wrote:
> >The wire protocol changes to turn SCRAM into a GSS-API mechanism are
> >minimal: just the OID-prefix on the first message.  And a section
> >describing the GSS-API related semantics (prot-ready etc).

Only if we go with compression of that OID (which we should), though the
change then is slightly more involved, IIRC, but still in the realm of
the trivial.

As for implementations, the more significant are the changes to go from
meeting whatever requirements of a SASL implementation's plug-in SPI to
meeting the requirements of a GSS-API implementation's plug-in SPI, plus
-optionally- providing a true SASL/GS2 implementation.

> If only it were that simple.  We're still evaluating doing SCRAM as GS2, 
> but it looks like it adds an extra redundant hash computation for both ends 
> and a bunch of cruft to every message.  I still think we should make it 
> concrete to see if the result is palatable, but I can't predict if we'll 
> get WG rough consensus on the result.

Simon was talking about what it would take to get a GSS mechanism out of
a SCRAM specification based on SCRAM-as-a-SASL/GS2 mechanism that is not
described primarily as a GSS-API mechanism to begin with.

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 mAOILH6Y059529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 11:21:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAOILHt2059528; Mon, 24 Nov 2008 11:21:17 -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 mAOIL6uX059514 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Mon, 24 Nov 2008 11:21:17 -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 mAOIKwCD004053 for <[e-mail]>; Mon, 24 Nov 2008 10:21:06 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 24 Nov 2008 10:20:58 -0800 (PST)
Received: from [10.1.110.5] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Mon, 24 Nov 2008 10:20:56 -0800 (PST)
Date: Fri, 21 Nov 2008 18:06:10 -0600
From: Chris Newman <[e-mail]>
Subject: Re: SCRAM and mechanism family
In-reply-to: <[e-mail]>
To: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Message-id: <0EBD68AA064ADB40A0591FCD@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]> <[e-mail]> <[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 November 20, 2008 22:33:00 +0100 Simon Josefsson <[e-mail]> 
wrote:
> The wire protocol changes to turn SCRAM into a GSS-API mechanism are
> minimal: just the OID-prefix on the first message.  And a section
> describing the GSS-API related semantics (prot-ready etc).

If only it were that simple.  We're still evaluating doing SCRAM as GS2, 
but it looks like it adds an extra redundant hash computation for both ends 
and a bunch of cruft to every message.  I still think we should make it 
concrete to see if the result is palatable, but I can't predict if we'll 
get WG rough consensus on the result.

		- 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 mAL7tmNA055587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Nov 2008 00:55:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAL7tmVH055586; Fri, 21 Nov 2008 00:55:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 mAL7tZCB055579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 21 Nov 2008 00:55:47 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L3QrS-0004R6-2b; Fri, 21 Nov 2008 08:55:33 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081121:[e-mail]::7hGCdqoeVp/x9Yg1:zKug
X-Hashcash: 1:22:081121:[e-mail]::Tmnk1q6/KC03+ly0:hxCB
Date: Fri, 21 Nov 2008 08:55:29 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 20 Nov 2008 16:24:21 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (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.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

>>It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
>>and supported in SASL via GS2, the mechanism name registered with IANA
>>will be the GS2-* name, not SCRAM-HMAC-SHA-1.
>>
> That is correct.
> But I wanted to resolve all outstanding issues except for GS2 framing
> and make the document self consistent.

Great.  To help the SCRAM document to prepare a GS2 name, here is text I
prepared, based on similar text for GS2+Krb5.  Someone needs to check
the computations, but that can happen later on.

X.Y SASL Mechanism Name for SCRAM

   The GSS-API OID for SCRAM is 1.3.6.1.4.1.11591.4.2 and its DER
   encoding is (in hex) 06 09 2B 06 01 04 01 DA 47 04 02.  The SHA-1
   hash is 29 06 29 12 AB 25 83 CD 02 92 1B 4E 2D D8 6A 40 CD D0 5D C2.
   Convert the first ten octets to binary, and re-group them in groups
   of 5, and convert them back to decimal, which results in these
   computations:

   hex:
   29 06 29 12 AB 25 83 CD 02 92

   binary:
   00101001 00000110 00101001 00010010 10101011
   00100101 10000011 11001101 00000010 10010010

   binary in groups of 5:
   00101 00100 00011 00010 10010 00100 10101 01011
   00100 10110 00001 11100 11010 00000 10100 10010

   decimal of each group:
   5 4 3 2 18 4 21 11 4 22 1 28 26 0 20 18

   base32 encoding:
   F E D C S E V L E W B 4 2 A U S

   The last step translate each decimal value using table 3 in Base32
   [RFC4648].  Thus the SASL mechanism name for SCRAM is
   "GS2-FEDCSEVLEWB42AUS".

/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 mAKMPdG6035735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 15:25:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKMPdWW035734; Thu, 20 Nov 2008 15:25:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKMPNoo035722 for <[e-mail]>; Thu, 20 Nov 2008 15:25:36 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.31.232] ((unknown) [130.129.31.232])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 20 Nov 2008 22:24:54 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 2008 16:24:21 -0600
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 and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1
>>with IANA.
>>    
>>
>It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
>and supported in SASL via GS2, the mechanism name registered with IANA
>will be the GS2-* name, not SCRAM-HMAC-SHA-1.
>
That is correct.
But I wanted to resolve all outstanding issues except for GS2 framing 
and make the document self consistent.

>Have we given up on supporting SCRAM as a GSS-API mechanism?
>
No.

>That would be bad news for me,
>I still see a long-term need for a password-based GSS-API mechanism.
>
>The wire protocol changes to turn SCRAM into a GSS-API mechanism are
>minimal: just the OID-prefix on the first message.  And a section
>describing the GSS-API related semantics (prot-ready etc).
>
>We could also let SCRAM move forward as a native SASL mechanism, write a
>separate short document that says SCRAM plus OID-prefix and some
>semantics is a password-based GSS-API mechanism.  The problem then is
>how to deal with native SCRAM vs SCRAM-via-GS2.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKLX9Lh033481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 14:33:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKLX9Pe033480; Thu, 20 Nov 2008 14:33:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKLX7ma033474 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 20 Nov 2008 14:33:08 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L3H97-0004Kz-89; Thu, 20 Nov 2008 22:33:05 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081120:[e-mail]::+hRlxzJa2ou9knb8:15Wl
X-Hashcash: 1:22:081120:[e-mail]::lX1DyIrhh+Qw2/nj:MUZ6
Date: Thu, 20 Nov 2008 22:33:00 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 20 Nov 2008 11:20:32 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1
> with IANA.

It just occurred to me that if we want SCRAM to be a GSS-API mechanism,
and supported in SASL via GS2, the mechanism name registered with IANA
will be the GS2-* name, not SCRAM-HMAC-SHA-1.  Have we given up on
supporting SCRAM as a GSS-API mechanism?  That would be bad news for me,
I still see a long-term need for a password-based GSS-API mechanism.

The wire protocol changes to turn SCRAM into a GSS-API mechanism are
minimal: just the OID-prefix on the first message.  And a section
describing the GSS-API related semantics (prot-ready etc).

We could also let SCRAM move forward as a native SASL mechanism, write a
separate short document that says SCRAM plus OID-prefix and some
semantics is a password-based GSS-API mechanism.  The problem then is
how to deal with native SCRAM vs SCRAM-via-GS2.

/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 mAKLPLjh033176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 14:25:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKLPLWa033175; Thu, 20 Nov 2008 14:25:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKLP8tb033144 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 20 Nov 2008 14:25:20 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L3H1J-0004Kt-4F; Thu, 20 Nov 2008 22:25:06 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081120:[e-mail]::m7XymlGuU/imdOHs:3/pF
X-Hashcash: 1:22:081120:[e-mail]::9IResAm2YmR9S/9t:MWQ4
X-Hashcash: 1:22:081120:[e-mail]::cyPplqVTSiHwoWfc:+0x0
Date: Thu, 20 Nov 2008 22:24:56 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 20 Nov 2008 11:05:17 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Arnt Gulbrandsen wrote:
>
>> One one hand, having a single name saves clutter. I know I can use
>> the same code for all SCRAM varieties if they're defined using the
>> same words in the same document.
>>
>> On another, how many varieties are expected in the foreseeable
>> future? 1? 2? A generic mechanism that covers one or two cases has
>> bad karma, and one that is meant to cover the unforeseeable future
>> in cryptography and computer security has really awful karma.
>>
>> So I think that overall maybe I agree with Simon.
>
> I wanted to write a small rant in reply ;-), but I've realized there
> might be a couple of related issues here:
>
> 1). Structure of the document - SCRAM currently written with an
> assumption that any hash function can be used with it
> 2). Definition of SCRAM-HMAC-SHA-1 and IANA registration.
>
> I am quite reluctant to change 1). Speaking personally I have plenty
> of of other things to do that I consider more important and I am not
> looking forward potentially creating more work for myself by
> hardcoding the hash name in various places of the document.

I have no objection to the current structure.  1) is good in that it
makes it easy to do a search-n-replace for SHA-1 with SHA-256 or SHA-3
when the need arise.

/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 mAKL0VG3032111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 14:00:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKL0V7E032110; Thu, 20 Nov 2008 14:00:31 -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 mAKL0KRP032091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 20 Nov 2008 14:00: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 mAKL0Dqt009776; Thu, 20 Nov 2008 16:00:14 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mAKL09bZ013579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Nov 2008 16:00:12 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mAKL09el006114; Thu, 20 Nov 2008 16:00:09 -0500 (EST)
To: [e-mail], [e-mail]
Subject: IETF73 SASL WG summary
From: Tom Yu <[e-mail]>
Date: Thu, 20 Nov 2008 16:00:09 -0500
Message-ID: <[e-mail]>
Lines: 44
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Spam-Flag: NO
X-Spam-Score: 0.00
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simple Authentication And Security Layer (SASL)
IETF73, Minneapolis, MN

Tuesday, November 18, 2008 at 1520-1720
=======================================

Chairs:

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

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

Alexey Melnikov talks about SCRAM, describing resolved issues.
Discussion about modified GS2 framing for easier (non-GSS)
implementation of SCRAM.  Sam Hartman previously gave three possible
alternatives.  Several opinions that option 3 is best; no objections.
Suggestion to prepare examples of GS2+krb5 and GS2+SCRAM to help
readers understand the encoding.

Kurt has submitted an I-D (this morning!) proposing moving CRAM-MD5 to
Historic status, and updating its IANA registry entry to "OBSOLETE".
The intent is to abandon current WG document draft-ietf-sasl-crammd5.
Strong opinions that Kurt's document be held from publication until
SCRAM is published; no objections.  General agreement that the IANA
registry entry for "usage" should remain "LIMITED" and contain
references to both 2195 and Kurt's document.

Kurt talks about 4422bis.  Some discussion about normative downrefs.

Action items:

* Tom - WGLC Kurt's CRAM-MD5-to-historic document
* Alexey, Sam, et al. - update docs for GS2 encoding (and SCRAM)
* implementors - help write GS2 encoding examples

Milestones:

Nov 08 - Initial RFC4422 impl. report
Nov 08 - Reach consensus on CRAM-MD5 successor approach (and update
       	 milestones accordingly)
Dec 08 - WGLC RFC4422bis and implementation report I-D
Jan 09 - WGLC DIGEST-MD5 replacement I-D
Jan 09 - WGLC GS2 I-D



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKHKx5s023171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 10:20:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKHKxx7023170; Thu, 20 Nov 2008 10:20: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 mAKHKwil023164 for <[e-mail]>; Thu, 20 Nov 2008 10:20:59 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.106] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 20 Nov 2008 17:20:57 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 2008 11:20:32 -0600
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> 1). Structure of the document - SCRAM currently written with an 
> assumption that any hash function can be used with it
> 2). Definition of SCRAM-HMAC-SHA-1 and IANA registration.
>
> I am quite reluctant to change 1). Speaking personally I have plenty 
> of of other things to do that I consider more important and I am not 
> looking forward potentially creating more work for myself by 
> hardcoding the hash name in various places of the document.
>
> Speaking of 2): we've actually discussed this during the WG meeting in 
> Minneapolis and the room consensus was to NOT register a family of 
> SCRAM-HMAC mechanisms, but only register SCRAM-HMAC-SHA-1 and add some 
> text that any further SCRAM-HMAC-* registrations would need to be done 
> on the case by case basis. I will update the document to match, unless 
> somebody has a strong objection.

I've updated my copy of the draft to only register SCRAM-HMAC-SHA-1 with 
IANA.
I've also added the following text:

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.

Comments?
(Is the text entirely consistent? I am wondering if instructing IANA not 
to register future SCRAM-HMAC mechanism without consulting the mailing 
list is in fact a registration of the new SCRAM-HMAC family of SASL 
mechanisms?)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKH63bB022120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 10:06:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKH63D5022119; Thu, 20 Nov 2008 10:06:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKH5q4n022108 for <[e-mail]>; Thu, 20 Nov 2008 10:06:03 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.106] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 20 Nov 2008 17:05:51 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 2008 11:05:17 -0600
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: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: SCRAM and mechanism family
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>

Arnt Gulbrandsen wrote:

> One one hand, having a single name saves clutter. I know I can use the 
> same code for all SCRAM varieties if they're defined using the same 
> words in the same document.
>
> On another, how many varieties are expected in the foreseeable future? 
> 1? 2? A generic mechanism that covers one or two cases has bad karma, 
> and one that is meant to cover the unforeseeable future in 
> cryptography and computer security has really awful karma.
>
> So I think that overall maybe I agree with Simon.

I wanted to write a small rant in reply ;-), but I've realized there 
might be a couple of related issues here:

1). Structure of the document - SCRAM currently written with an 
assumption that any hash function can be used with it
2). Definition of SCRAM-HMAC-SHA-1 and IANA registration.

I am quite reluctant to change 1). Speaking personally I have plenty of 
of other things to do that I consider more important and I am not 
looking forward potentially creating more work for myself by hardcoding 
the hash name in various places of the document.

Speaking of 2): we've actually discussed this during the WG meeting in 
Minneapolis and the room consensus was to NOT register a family of 
SCRAM-HMAC mechanisms, but only register SCRAM-HMAC-SHA-1 and add some 
text that any further SCRAM-HMAC-* registrations would need to be done 
on the case by case basis. I will update the document to match, unless 
somebody has a strong objection.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKFabpE017672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 08:36:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKFabpR017671; Thu, 20 Nov 2008 08:36:37 -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 mAKFaasJ017665 for <[e-mail]>; Thu, 20 Nov 2008 08:36:37 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.106] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 20 Nov 2008 15:36:35 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 2008 09:36:12 -0600
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 and mechanism family
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:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>I brought this up on the jabber chat during the WG presentation of
>>>SCRAM, but it may be useful to repeat here to get feedback.
>>>
>>>Why does SCRAM needs to be defined as a mechanism family?
>>>      
>>>
>>It doesn't have to. But the document already defines any SCRAM
>>mechanism as if the hash function is pluggable. I personally like it
>>like that and I don't see a reason to change the document.
>>    
>>
>>>If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
>>>obvious reason for defining SCRAM as a family, taking the current SCRAM
>>>document and replacing SHA-1 with SHA-256 is possible.
>>>
>>>The non-family approach has the benefit of making it simple to introduce
>>>improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
>>>necessary.
>>>      
>>>
>>While this is true, I would hate to have a set of similar, but
>>slightly different mechanisms.
>>If this happens, I would be strongly in favour of changing the
>>mechanism prefix name.
>>    
>>
>For a non-family mechanism, there is no prefix, so changing the name
>from SCRAM-HMAC-SHA-1 to SCRAM-HMAC-SHA-256 will change the name and
>make them non-equivalent from a SASL library perspective.
>  
>
I was thinking more from a developer prospective: trying to remember 
subtile differences between similar things is hard.

>But I don't care strongly, I was trying to understand if there were a
>strong reason to do this rather than a preference.
>  
>
No strong 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 mAKFK2pq017018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 08:20:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKFK27a017017; Thu, 20 Nov 2008 08:20:02 -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 mAKFJnA3016999 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 20 Nov 2008 08:20:01 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L3BJs-0002zJ-01; Thu, 20 Nov 2008 16:19:48 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081120:[e-mail]::uwIJhkWWlvShdQmO:1wES
X-Hashcash: 1:22:081120:[e-mail]::43IRkPevjw9xKNOx:6eAL
Date: Thu, 20 Nov 2008 16:19:47 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 20 Nov 2008 08:00:22 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>I brought this up on the jabber chat during the WG presentation of
>>SCRAM, but it may be useful to repeat here to get feedback.
>>
>>Why does SCRAM needs to be defined as a mechanism family?
>>  
>>
> It doesn't have to. But the document already defines any SCRAM
> mechanism as if the hash function is pluggable. I personally like it
> like that and I don't see a reason to change the document.
>
>>If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
>>obvious reason for defining SCRAM as a family, taking the current SCRAM
>>document and replacing SHA-1 with SHA-256 is possible.
>>
>>The non-family approach has the benefit of making it simple to introduce
>>improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
>>necessary.
>>  
>>
> While this is true, I would hate to have a set of similar, but
> slightly different mechanisms.
> If this happens, I would be strongly in favour of changing the
> mechanism prefix name.

For a non-family mechanism, there is no prefix, so changing the name
from SCRAM-HMAC-SHA-1 to SCRAM-HMAC-SHA-256 will change the name and
make them non-equivalent from a SASL library perspective.

But I don't care strongly, I was trying to understand if there were a
strong reason to do this rather than a preference.

/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 mAKFG9CS016872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 08:16:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKFG9cI016871; Thu, 20 Nov 2008 08:16:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKFFvnh016863 for <[e-mail]>; Thu, 20 Nov 2008 08:16:08 -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 880654AC95; Thu, 20 Nov 2008 16:15:56 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.0.4) with esmtp id 1227194156-1323-1/6/17 for [e-mail]; Thu, 20 Nov 2008 16:15:56 +0100
Message-Id: <[e-mail]>
Date: Thu, 20 Nov 2008 16:14:58 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: SCRAM and mechanism family
References: <[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>

One one hand, having a single name saves clutter. I know I can use the 
same code for all SCRAM varieties if they're defined using the same 
words in the same document.

On another, how many varieties are expected in the foreseeable future? 
1? 2? A generic mechanism that covers one or two cases has bad karma, 
and one that is meant to cover the unforeseeable future in cryptography 
and computer security has really awful karma.

So I think that overall maybe I agree with Simon.

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 mAKE0wsd011759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 07:00:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKE0wBh011758; Thu, 20 Nov 2008 07:00: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 mAKE0kq6011745 for <[e-mail]>; Thu, 20 Nov 2008 07:00:57 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.106] ((unknown) [75.146.152.44])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 20 Nov 2008 14:00:44 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 20 Nov 2008 08:00:22 -0600
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 and mechanism family
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:

>I brought this up on the jabber chat during the WG presentation of
>SCRAM, but it may be useful to repeat here to get feedback.
>
>Why does SCRAM needs to be defined as a mechanism family?
>  
>
It doesn't have to. But the document already defines any SCRAM mechanism 
as if the hash function is pluggable. I personally like it like that and 
I don't see a reason to change the document.

>If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
>obvious reason for defining SCRAM as a family, taking the current SCRAM
>document and replacing SHA-1 with SHA-256 is possible.
>
>The non-family approach has the benefit of making it simple to introduce
>improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
>necessary.
>  
>
While this is true, I would hate to have a set of similar, but slightly 
different mechanisms.
If this happens, I would be strongly in favour of changing the mechanism 
prefix name.

>I think SASL mechanism families introduce complexity for little gain,
>but I'd be interested to understand why it was added here.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAKC3MQC003292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Nov 2008 05:03:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAKC3Mle003291; Thu, 20 Nov 2008 05:03:22 -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 mAKC3864003233 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 20 Nov 2008 05:03:21 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L38FX-0002mF-4r for [e-mail]; Thu, 20 Nov 2008 13:03:07 +0100
X-Hashcash: 1:22:081120:[e-mail]::TE9nsU2eZxTvwdbK:bl+u
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: SCRAM and mechanism family
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 20 Nov 2008 13:03:06 +0100
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I brought this up on the jabber chat during the WG presentation of
SCRAM, but it may be useful to repeat here to get feedback.

Why does SCRAM needs to be defined as a mechanism family?

If we ever needs to define SCRAM-HMAC-SHA-256, which appears as the most
obvious reason for defining SCRAM as a family, taking the current SCRAM
document and replacing SHA-1 with SHA-256 is possible.

The non-family approach has the benefit of making it simple to introduce
improvements to the the SCRAM-HMAC-SHA-256 mechanism if deemed
necessary.

I think SASL mechanism families introduce complexity for little gain,
but I'd be interested to understand why it was added here.

/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 mAIMnB5g082912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 15:49:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIMnBcT082911; Tue, 18 Nov 2008 15:49:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-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 mAIMn8AV082905 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 15:49:08 -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 mAIMn5oc006318 for <[e-mail]>; Tue, 18 Nov 2008 14:49:08 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 18 Nov 2008 14:49:05 -0800 (PST)
Received: from [172.28.172.84] ([130.129.31.220]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Tue, 18 Nov 2008 14:49:05 -0800 (PST)
Date: Tue, 18 Nov 2008 16:49:03 -0600
From: Chris Newman <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-00.txt
In-reply-to: <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-id: <19F73C479AC12F5FF3D61B27@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nit: the "changes since last version" doesn't mention the examples were 
altered.

		- Chris

--On September 9, 2008 12:45:01 -0700 [e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Simple Authentication and Security Layer
> Working Group of the IETF.
>
> 	Title		: Simple Authentication and Security Layer (SASL)
> 	Author(s)	: A. Melnikov, K. Zeilenga
> 	Filename	: draft-ietf-sasl-4422bis-00.txt
> 	Pages		: 33
> 	Date		: 2008-8-31
> 	
> The Simple Authentication and Security Layer (SASL) is a framework
>    for providing authentication and data security services in
>    connection-oriented protocols via replaceable mechanisms.  It
>    provides a structured interface between protocols and mechanisms.
>    The resulting framework allows new protocols to reuse existing
>    mechanisms and allows old protocols to make use of new mechanisms.
>    The framework also provides a protocol for securing subsequent
>    protocol exchanges within a data security layer.
>
>    This document describes how a SASL mechanism is structured, describes
>    how protocols include support for SASL, and defines the protocol for
>    carrying a data security layer over a connection.  In addition, this
>    document defines one SASL mechanism, the EXTERNAL mechanism.
>
>    This document obsoletes RFC 4422 [[when approved]].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-4422bis-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIL1Fmg077731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 14:01:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIL1Fmv077730; Tue, 18 Nov 2008 14:01:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIL143l077711 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 14:01:15 -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 mAIL14nO022101 for <[e-mail]>; Tue, 18 Nov 2008 13:01:04 -0800 (PST)
Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Tue, 18 Nov 2008 13:01:03 -0800 (PST)
Received: from [172.28.172.84] ([130.129.31.220]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <[e-mail]>; Tue, 18 Nov 2008 13:01:00 -0800 (PST)
Date: Tue, 18 Nov 2008 15:00:55 -0600
From: Chris Newman <[e-mail]>
Subject: Re: ABNF for the three cases of GS2
In-reply-to: <[e-mail]>
To: Sam Hartman <[e-mail]>, [e-mail]
Message-id: <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F>
MIME-version: 1.0
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I was unaware this was stalled waiting for my response until I was told 
yesterday; apologies for not responding sooner.

I'm finding it very difficult to get my head around this at the moment due 
to the nested ABNF.  To attempt to better understand it, I'm going to 
unfold the nested references with some simplifications.  First, "gunk" is 
something I believe to be constant when sent by SASL-SCRAM implementations 
and ignored when received by SASL-SCRAM implementations (albeit included in 
a hash if necessary) -- that includes all the security layer stuff since I 
assume SASL-SCRAM implementations will always negotiate off security 
layers.  Second, I'm dropping hash-list (we agreed to move that to the mech 
name), the non-relevant syntax and extensibility for now.  Third, I'm only 
showing a data item the first time it is transferred (it's sometimes 
helpful to transfer an item more than once to simplify the code, but that's 
an optimization we need not consider at the moment).

So I think we end up with (please correct me if this is wrong):

Case 1:

C1: b64(gunk,c-nonce,username) ":" %x00
S1: b64(s-nonce,salt,iter-count) ":"
C2: b64(b64(channel-bind),b64(ClientProof))
      ":" b64(b64(<MIC-of-something?>),authzid,gunk)
S2: b64(b64(ServerSignature)) ":" b64(b64(<MIC-of-something?>),gunk)

I'm don't understand how a SASL-SCRAM implementation is supposed to 
generate the <MIC-of-something> that GSS wrap does.  Does SASL-SCRAM just 
set this to 0?  I know how the ClientProof is computed (which implicitly 
includes a MIC), I don't understand the MIC although it doesn't matter if I 
can set it to 0 and ignore it.

I don't understand why two sets of channel bindings appear to be present, 
but I'm assuming that SASL-SCRAM treats the GSS-channel-binding as gunk 
(send constant / ignore on receipt) for simplicity.  If SASL-SCRAM 
implementation has to do something else I need to understand what it's 
expected to do to understand the proposal.

I'm confused about the placement of authzid, since it needs to be included 
in the SCRAM computations.  The current SCRAM spec includes it in the first 
client message (optionally).  It's harmless moving it to the second client 
message but I don't really understand why it ends up in the second b64 blob.

I'm not fond of this approach due to the three levels of base64-encoding 
that will occur in many SASL profiles (e.g. IMAP) that use base64 as a 
wrapper for SASL exchanges.  That extra middle layer makes the interesting 
content unreadable to any debug/logging mechanism provided in the protocol 
or SASL layer -- debugging/diagnostics have to be put directly in the SCRAM 
layer after that middle layer is unwrapped.

Case 2:

C1: gunk,c-nonce,username delim
S1: s-nonce,salt,iter-count delim
C2: b64(channel-bind),b64(ClientProof) delim 
b64(<MIC-of-something?>),authzid,gunk
S2: b64(ServerSignature) delim b64(<MIC-of-something?>),gunk

Escaping is used where necessary to avoid delim.  Other than not wanting a 
NUL delim due to the negative impact it has on debugging (I'd consider ^A), 
this seems workable assuming MIC-of-something isn't needed by SASL-SCRAM.

Case 3:

C1: "ctx=" gunk,c-nonce,username
S1: "ctx=" s-nonce,salt,iter-count
C2: "mic=" b64(<MIC-of-something?>),gunk,authzid ",ctx=" 
b64(channel-bind),b64(ClientProof)
S2: "mic=" b64(<MIC-of-something?>),gunk ",ctx=" b64(ServerSignature)

I'm not sure I understand how this is different from case 2.  It seems 
there's just a different delimiter (specifically, ",ctx=") and the GSS 
stuff is moved to the beginning.  Regardless, it seems fine to me.

		- Chris

--On August 11, 2008 17:14:33 -0400 Sam Hartman <[e-mail]> 
wrote:
> I have put together ABNF for the three cases of GS2.
>
> A few notes:
>
> * I've punted on the whole OID issue at the beginning of the client
>   context token, defining a rule oidgunk that we'll need to figure
>   out.  That may involve negotiation with kitten.
>
> * I'm only providing Grammar for the parts of scram that SASL actually
>   uses.  Nico at least believes that the GSS-API mechanism should
>   provide sequencing.  I've included enough stuff that a pure SASL
>   mechanism would parse and ignore any such usage but have not
>   explored it.
>
> * There are two channel binding slots: one used by sasl in
>   scram-wrap-c2-inner and one used by non-SASL GSS-API applications in
> scram-c2-ctx
>
> * Most of the protocol is the same between all three cases.
>
> * This assumes that gs2 implementations are required to send the
>   mic/wrap token as soon as possible and that scram implementations
>   are required to be prot_ready when the client final message is sent.
>
> My current preference is a moderate preference for case 2.  I might
> like case 3 better if someone suggested a better way to determine the
> end of the non-context part.
>
> ; Some rules used by most of the grammars:
> gs2-to-be-protected = qop ["," maxbuf] ["," cbqop "," channelbinding]
>     ["," authzid] ["," 1*extension]
> qop = "qop=" qopvalue *( "+" qopvalue)
> qopvalue = "none" ; no security layer
>     / "integ" ; integrity protection
>     / "conf" ; confidentiality protection
>     / "cbgood" ; channel binding validated (server to client)
> maxbuf = "maxbuf=" digits
> cbqop = "cbqop=" qopvalue *( "+" qopvalue); QOPs that can be used if
> channel binding succeeds channelbinding = "cb=" base64
> authzid = "authzid=" base64
> extension = alphanum "=" *extensionchar
> extensionchar = value-char
> value-safe-char = %20-2B / %2D-3C / %3E-7E /
> 		  UTF8-2 / UTF-3 / UTF8-4
> 		  ;; UTF8-char except CTL, "=", and ",".
>
> value-char      = value-safe-char / "="
>
> ; The scram message parts that are constant across all three cases
> scram-c1-ctx = oidgunk username "," hash-list "," nonce
> ; oidgunk needs to be discussed on the list
> scram-s1-ctx = nonce "," hash-list "," salt "," iteration-count
> scram-c2-ctx = nonce "," gss-channel-binding "," proof
> ; gss-channel-binding is used  for non-SASL GSS-API
> ; but not for sasl apps
>
> scram-s2-ctx = verifier
>
> ; The content that gets wrapped is also constant across all three cases
> ; We don't consider it desirable that scram have a security layer.
> ; However it seems like scram is going to be enough of a gss-api mechanism
> ; that it will end up having a well-defined security layer.
> ; A SCRAM implementation with a full GSS-API  implementation MAY end up
> using  ; security layers and as such all SCRAM implementations need to
> parse qops  and ; maxbuf specifications. However pure SASL implementation
> can send a limited set  of responses ; and need not actually implement
> security layers
> ; The following rules demonstrate what will be carried between  two sasl-
> ; only scram  implementations that do not support security layers.
> ; the following two rules are the scram wrap from client to server and
> server to client saslscram-wrap-c2-inner = "qop=none" ["," "cbqop=none"
> "," channelbinding]      ["," authzid] [ "," 1*extension]
> saslscram-wrap-s2-inner = "qop=none" [ "+cbgood" ] [ "," 1*extension]
> ; and here are rules for what implementations must parse
> scram-wrap-c2-inner = qop ["," maxbuf ] ["," cbqop "," channelbinding]
> ["," authzid]      ["," 1*extension]
> ; The following rule could probably be simplified  as it's not clear
> maxbuf ; will ever appear in the s2 message unless you have two
> gs2-implementations  ; talking that have actually decided to use security
> layers
> scram-wrap-s2-inner = qop ["," maxbuf] ["," 1*extension]
>
>
> ; Grammar: case 1 two base 64 tokens
>
> gs2-message = gs2-context "," gs2-wrap
> gs2-context = base64 ; completely defined by the mechanism
> gs2-wrap = base64 ; processed by the mechanism but including the data
> from gs2-wrap-inner gs2-wrap-inner = gs2-to-be-protected
> scram-wrap = "mic="base64 ["," 1*extension] "," "d=" *octet ; MIC and
> integrity protected data ; So, that would make the SCRAM c2 message look
> like:
> scram-c2-wrap = "mic=" base64 [ "," 1*extension] ",d=" scram-wrap-c2-inner
> scram-s2-wrap = "mic=" base64 ["," 1*extension] ",d=" scram-wrap-s2-inner
> ; So, the client sends base64(scram-c1-ctx):null
> ; the server sends base64(scram-s1-ctx):nothing
> ; the client sends base64(scram-c2-ctx):base64(scram-c2-wrap)
> ; the server sends base64(scram-s2-ctx):base64(scram-s2-wrap)
>
> ; Grammar 2: Escaping
> ; null null encodes null
> ; null "," separates the context from wrap token
> ; Feel free to use a different escaping mechanism
> escape-char = %x01-ff / (%x00 %x00)
> escaped = 1*escape-char
> delim = %x00 ","
> gs2-message = gs2-ctx delim gs2-wrap
> gs2-ctx = escaped
> gs2-wrap = escaped
> ; It happens that the scram messages below conform to escaped
> scram-wrap-part = "mic=" base64 ["," 1*extension] ",d="
> scram-wrap = scram-wrap-part escaped
>
> scram-c1 = scram-c1-ctx delim
> scram-s1 = scram-s1-ctx delim
> scram-c2 = scram-c2-ctx delim scram-wrap-part scram-wrap-c2-inner
> scram-s2 = scram-s2-ctx delim scram-wrap-part scram-wrap-s2-inner
>
> ; Grammar 3: mic and base64
> ; In this case we assume that scram-mic is a fixed-length binary hmac
> followed by extra stuff  ; used by GSS-API but not SASL for sequencing
> and replay
> gs2-message = [gs2-mic gs2-stuff  ","] "ctx="gs2-ctx
> ; Note that determining where the end of the MIC is a bit tricky; it
> extends to ; but does not include the final comma in gs2-stuff. You don't
> know you are at ; the end until you read ctx
> gs2-mic = "mic=" base64 "," ; base64 of gss_getmic of gs2-stuff
> gs2-stuff = gs2-to-be-protected
> gs2-ctx = 1*octet
> scram-c1 = "ctx"= scram-c1-ctx
> scram-s1 = "ctx"= scram-s1-ctx
> scram-c2 = gs2-mic scram-wrap-c2-inner ",ctx=" scram-c2-ctx
> scram-s2 = gs2-mic scram-wrap-s2-inner ",ctx=" scram-s2-ctx
>
>






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIHF4Eo063120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 10:15:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIHF4p6063119; Tue, 18 Nov 2008 10:15:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 mAIHEp2Z063098 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 10:15:03 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-27-189.bredband.comhem.se ([80.216.27.189] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <[e-mail]>) id 1L2UA4-00018V-M9; Tue, 18 Nov 2008 18:14:49 +0100
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: Fwd: I-D ACTION:draft-zeilenga-sasl-crammd5-00.txt
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081118:[e-mail]::X85rlZXNMf5fXGZh:1WdY
X-Hashcash: 1:22:081118:[e-mail]::cZAOD2t0vCt9rTfs:8Or2
Date: Tue, 18 Nov 2008 18:14:47 +0100
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 18 Nov 2008 10:54:00 -0600")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.2.3 (2007-08-08) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> I ask the WG to consider this I-D as an alternative to
> draft-ietf-sasl-
> crammd5.

+1

/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 mAIGsE2U061688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:54:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIGsE2j061687; Tue, 18 Nov 2008 09:54:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIGs3mt061671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 09:54:13 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.79.21] ([130.129.79.21]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id mAIGs02x059804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Tue, 18 Nov 2008 16:54:02 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
Content-Type: multipart/mixed; boundary=Apple-Mail-5--388062648
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Fwd: I-D ACTION:draft-zeilenga-sasl-crammd5-00.txt 
Date: Tue, 18 Nov 2008 10:54:00 -0600
References: <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Apple-Mail-5--388062648
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I ask the WG to consider this I-D as an alternative to draft-ietf-sasl- 
crammd5.

Also, I recuse myself from all chair actions regarding the SASL WG's  
CRAM-MD5 work item.

-- Kurt

Begin forwarded message:

> From: [e-mail]
> Date: November 18, 2008 10:15:01 AM CST
> To: [e-mail]
> Subject: I-D ACTION:draft-zeilenga-sasl-crammd5-00.txt
> Reply-To: [e-mail]
> List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: CRAM-MD5 to historic
> 	Author(s)	: K. Zeilenga
> 	Filename	: draft-zeilenga-sasl-crammd5-00.txt
> 	Pages		: 6
> 	Date		: 2008-11-18
> 	
>  This document recommends the retirement of the CRAM-MD5  
> authentication
>  mechanism, and discusses the reasons for doing so.  This document
>  recommends RFC 2195 and its predecessor, RFC 2095, be moved to
>  Historic status.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zeilenga-sasl-crammd5-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

--Apple-Mail-5--388062648
Content-Disposition: attachment;
	filename=mime-attachment
Content-Type: message/external-body;
	x-unix-mode=0666;
	name="mime-attachment"
Content-Transfer-Encoding: 7bit

Content-Type: text/plain<BR>Content-ID: &lt;[e-mail]&gt;<BR><BR>
--Apple-Mail-5--388062648
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--Apple-Mail-5--388062648--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAH5cEo2037049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Nov 2008 22:38:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAH5cEKW037048; Sun, 16 Nov 2008 22:38:14 -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 mAH5c24G037037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 16 Nov 2008 22:38:13 -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 mAH5c0ZL029041 for <[e-mail]>; Mon, 17 Nov 2008 00:38:00 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mAH5bxSD028815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 17 Nov 2008 00:38:00 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mAH5bxNS027691; Mon, 17 Nov 2008 00:37:59 -0500 (EST)
To: [e-mail]
Subject: SASL and KRB-WG Time Change
From: Tom Yu <[e-mail]>
Date: Mon, 17 Nov 2008 00:37:59 -0500
Message-ID: <[e-mail]>
Lines: 79
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
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>

--=-=-=

Note the time change.  SASL will meet at 15:20 on Tuesday, instead of
the previously-scheduled 13:00.


--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <[e-mail]>
Received: from po9.mit.edu ([unix socket])
	by po9.mit.edu (Cyrus v2.1.5) with LMTP; Sun, 16 Nov 2008 20:10:03 -0500
X-Sieve: CMU Sieve 2.2
Received: from fort-point-station.mit.edu by po9.mit.edu (8.13.6/4.7) id mAH1A2XX020975; Sun, 16 Nov 2008 20:10:02 -0500 (EST)
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id mAH19sd7003355
	for <[e-mail]>; Sun, 16 Nov 2008 20:09:54 -0500 (EST)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
	by mit.edu (Spam Firewall) with ESMTP
	id 3B7921250B2E; Sun, 16 Nov 2008 20:09:30 -0500 (EST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 91D283A6405;
	Sun, 16 Nov 2008 17:09:29 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A42293A684A
	for <[e-mail]>; Sun, 16 Nov 2008 17:09:28 -0800 (PST)
X-Spam-Flag: NO
X-Spam-Score: 0.01
X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 
	RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id MLHvjFI4zEXh for <[e-mail]>;
	Sun, 16 Nov 2008 17:09:28 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14])
	by core3.amsl.com (Postfix) with ESMTP id 2283A3A6405
	for <[e-mail]>; Sun, 16 Nov 2008 17:09:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by thunder2.amsl.com (Postfix) with ESMTP id 676127FC2
	for <[e-mail]>; Sun, 16 Nov 2008 17:09:54 -0800 (PST)
Received: from mail.amsl.com ([64.170.98.20])
	by localhost (thunder2.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id aBImqYMKMxQk for <[e-mail]>;
	Sun, 16 Nov 2008 17:09:54 -0800 (PST)
Received: from [130.129.63.252] (unknown [130.129.63.252])
	by thunder2.amsl.com (Postfix) with ESMTP id 243AE4819E
	for <[e-mail]>; Sun, 16 Nov 2008 17:09:54 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Date: Sun, 16 Nov 2008 19:09:26 -0600
X-Mailer: Apple Mail (2.752.3)
From: All IETF 73 Attendees <[e-mail]>
Subject: [73all] SASL and KRB-WG Time Change
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: All IETF 73 Attendees <73all.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/73all>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/73all>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/73all>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]
X-Scanned-By: MIMEDefang 2.42
Lines: 10
MIME-Version: 1.0

SASL will now meet at 1520-1700 on Tuesday instead of 1300-1500.

KRB-WG will now meet at 1300-1500 on Tuesday instead of 1520-1700.

Both meetings will meet in the Rochester room.

_______________________________________________
73All mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/73all

--=-=-=--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAEU8u2053988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 07:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAAEU8H5053985; Mon, 10 Nov 2008 07:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAEU7F9053978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 10 Nov 2008 07:30:07 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id mAAEU6mq055672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Nov 2008 14:30:07 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Tom Yu <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: making progress on CRAM-MD5 before IETF73
Date: Mon, 10 Nov 2008 06:30:06 -0800
References: <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: 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 Nov 6, 2008, at 1:12 PM, Tom Yu wrote:

> Is there any objection to Frank's suggestion about adding Simon's
> PLAIN/CRAM comparison text?  I have heard none so far, and plan to ask
> Lyndon to update the draft accordingly.


Aside from issues with the particular text Simon suggested (see list  
archives), I have a general concern with inclusion of such text.   It  
will likely be a lightening rod for contentious discussions in the WG  
and the IESG.  It's not clear to me whether we'll reach consensus on a  
particular text.  And as we simply don't need to, why bother?   That  
is, I rather we focus on building consensus on the specification less  
this text.

-- 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 mAAEHHF7051452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2008 07:17:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAAEHHuq051451; Mon, 10 Nov 2008 07:17:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAAEH5LM051421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 10 Nov 2008 07:17:16 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id mAAEH4xp055039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Nov 2008 14:17:04 GMT (envelope-from [e-mail])
Cc: Hallvard B Furuseth <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Tom Yu <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: SCRAM storage in LDAP (Re: SASL WG status, 11/5)
Date: Mon, 10 Nov 2008 06:17:04 -0800
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: 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 Nov 6, 2008, at 12:26 PM, Tom Yu wrote:

>
> Hallvard B Furuseth <[e-mail]> writes:
>
>> Tom Yu writes:
>>> SCRAM:
>>>  * LDAP storage of auth info
>>>        - WG to consider draft-melnikov-sasl-scram-ldap-00
>>
>> Why not authPassword from RFC 3112?  Value something like
>>   scram-hmac-sha1$<iter-count>:<salt>$<stored-key>:<server-key>
>> or scram-hmac-sha1-<iter-count>$<salt>$<stored-key>:<server-key>
>> where salt and keys are base64-encoded.
>>
>> For that matter, I've missed why this is a SASL draft instead
>> of an ldapext draft.  Proof of concept for SCRAM, maybe?
>
> Chris Newman stated that he would not implmenent SCRAM if there were
> no published way to store its authentication secrets in LDAP.  I have
> no strong opinion either way on whether to adopt this draft as a SASL
> WG item, but I think it needs to get published somehow.

I have a mild preference for engineering this outside of the WG.

-- 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 mA9J5cm8014596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 12:05:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA9J5cs1014595; Sun, 9 Nov 2008 12:05:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9J5Zmq014585 for <[e-mail]>; Sun, 9 Nov 2008 12:05:37 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.54.137] (92.40.54.137.sub.mbb.three.co.uk [92.40.54.137])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 9 Nov 2008 19:05:32 +0000
Message-ID: <[e-mail]>
Date: Sun, 09 Nov 2008 19:05:00 +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: [e-mail]
Subject: Re: A minor issue with hash function name IANA registry defined by RFC 4572
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> RFC 4572 established an IANA registry for hash function names:
> <http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml>. 
> All function names defined so far are in lowercase. SASL mechanism 
> names only allow for uppercase letters.
> I think the registry need to be updated to restrict which US-ASCII 
> characters are allowed in textual representations of a hash function 
> name. It might also be a good idea to say that hash function names are 
> case insensitive.

Actually, RFC 4572 has ABNF for the hash function name, but it is not 
mentioned in the IANA registration. The document is referencing <token> 
from RFC 4566, which is defined:

   token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                         / %x41-5A / %x5E-7E

   token =               1*(token-char)

This is still too permissive for SASL mechanism names, which only allow 
uppercase letters, digits, "-" and "_".



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9IiLY5013521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Nov 2008 11:44:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA9IiLSJ013520; Sun, 9 Nov 2008 11:44:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA9Ii94S013507 for <[e-mail]>; Sun, 9 Nov 2008 11:44:20 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.54.137] (92.40.54.137.sub.mbb.three.co.uk [92.40.54.137])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 9 Nov 2008 18:44:06 +0000
Message-ID: <[e-mail]>
Date: Sun, 09 Nov 2008 18:43:34 +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: [e-mail]
Subject: A minor issue with hash function name IANA registry defined by RFC 4572
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>

RFC 4572 established an IANA registry for hash function names:
<http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml>. 
All function names defined so far are in lowercase. SASL mechanism names 
only allow for uppercase letters.
I think the registry need to be updated to restrict which US-ASCII 
characters are allowed in textual representations of a hash function 
name. It might also be a good idea to say that hash function names are 
case insensitive.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6LCgp1042091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 14:12:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6LCgkZ042090; Thu, 6 Nov 2008 14:12:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 mA6LCf7k042075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 14:12:41 -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 mA6LCdCG022722 for <[e-mail]>; Thu, 6 Nov 2008 16:12:39 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mA6LCcET026234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 6 Nov 2008 16:12:39 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mA6LCcOI027773; Thu, 6 Nov 2008 16:12:38 -0500 (EST)
To: [e-mail]
Subject: making progress on CRAM-MD5 before IETF73
From: Tom Yu <[e-mail]>
Date: Thu, 06 Nov 2008 16:12:38 -0500
Message-ID: <[e-mail]>
Lines: 67
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>

What remains to be done on CRAM-MD5?  I outlined some of the items in
my draft IETF73 agenda, but I would like to make progress on these
before that meeting.

* whether to change the status of RFC 2195 (and maybe RFC 2095)
* whether to change the CRAM-MD5 IANA registry entry
* intended track of draft-ietf-sasl-crammd5-10

Additionally, Frank Ellerman has asked for the document to include
Simon Josefsson's summary comparison of PLAIN and CRAM-MD5.

Is there any objection to Frank's suggestion about adding Simon's
PLAIN/CRAM comparison text?  I have heard none so far, and plan to ask
Lyndon to update the draft accordingly.

2195/2095 Status:

It may be best to explicitly move 2095 and 2195 to Historic in
conjunction with publishing this I-D, regardless of its actual track.

IANA Registry Entry:

The existing registry entry for CRAM-MD5 says "LIMITED" for intended
usage.  The wording of the current I-D also implies that the listing
should remain "LIMITED", despite not giving the "intended usage" field
in the IANA Considerations section.  If we intend to change this
registry entry, this change should be in the IANA Considerations
section, and the requested registry change should be consistent with
the rest of the document.

Intended Status:

I have heard strong opinions on both sides from WG participants about
the intended standards status of the current I-D.  Previous WG
consensus was to publish the I-D as Informational, despite the
proclamation of "Intended status: Standards Track" on the current I-D.
The consensus was uneasy at best.  This document has dragged on for an
embarrassingly long time, and a number of WG participants just want to
get it published.

I observe that, as with the IANA registry entry mentioned above, the
existing text in the document is not really consistent with a protocol
that we intend to be on the standards track.  I suggest that any WG
participants who wish for the I-D to publish on the standards track
work on making the document text consistent with this intent.

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

Does anyone disagree with my above conclusions that text changes will
be necessary to either publish on the standards track or to change the
IANA registry entry?

My evaluation of the state of this document and of this WG indicates
that the way to most quickly get this document published is:

* Add Simon's comparison text
* Change intended status to "Informational"

and possibly

* Request that 2095 and 2195 be marked "Historic"

I request that any WG participants who want this document to be on the
standards track or who want the intended usage in the IANA registry
changed to declare, before IETF73, their intent to help produce the
required text changes rapidly, along with a proposed schedule for
doing so.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6KQxDL037409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 13:26:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6KQxjT037408; Thu, 6 Nov 2008 13:26:59 -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 mA6KQw5H037399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 13:26:58 -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 mA6KQuHj013232; Thu, 6 Nov 2008 15:26:56 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mA6KQtHW006762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Nov 2008 15:26:55 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mA6KQtVZ027029; Thu, 6 Nov 2008 15:26:55 -0500 (EST)
To: Hallvard B Furuseth <[e-mail]>
Cc: [e-mail]
Subject: SCRAM storage in LDAP (Re: SASL WG status, 11/5)
References: <[e-mail]> <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Thu, 06 Nov 2008 15:26:55 -0500
In-Reply-To: <[e-mail]> (Hallvard B. Furuseth's message of "Thu, 6 Nov 2008 12:15:27 +0100")
Message-ID: <[e-mail]>
Lines: 19
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>

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

> Tom Yu writes:
>> SCRAM:
>>   * LDAP storage of auth info
>>         - WG to consider draft-melnikov-sasl-scram-ldap-00
>
> Why not authPassword from RFC 3112?  Value something like
>    scram-hmac-sha1$<iter-count>:<salt>$<stored-key>:<server-key>
> or scram-hmac-sha1-<iter-count>$<salt>$<stored-key>:<server-key>
> where salt and keys are base64-encoded.
>
> For that matter, I've missed why this is a SASL draft instead
> of an ldapext draft.  Proof of concept for SCRAM, maybe?

Chris Newman stated that he would not implmenent SCRAM if there were
no published way to store its authentication secrets in LDAP.  I have
no strong opinion either way on whether to adopt this draft as a SASL
WG item, but I think it needs to get published somehow.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6KNvZ6037206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 13:23:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6KNvwY037205; Thu, 6 Nov 2008 13:23:57 -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 mA6KNjK7037189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 13:23:56 -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 mA6KNg1m010369; Thu, 6 Nov 2008 15:23:42 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mA6KNfo6005389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Nov 2008 15:23:42 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mA6KNfLP027003; Thu, 6 Nov 2008 15:23:41 -0500 (EST)
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: draft agenda IETF73 SASL WG session
References: <[e-mail]> <[e-mail]>
From: Tom Yu <[e-mail]>
Date: Thu, 06 Nov 2008 15:23:41 -0500
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 06 Nov 2008 10:26:55 +0000")
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>

Alexey Melnikov <[e-mail]> writes:

> Tom Yu wrote:

>>* CRAM-MD5 - 30 min
>>  - fate of RFC 2195
>>  - fate of CRAM-MD5 IANA registry entry
>>  - track of draft-ietf-sasl-crammd5-10
>>
>>* other technical discussion - 60 min
>>  - GS2
>>  - SCRAM
>>  - interop report
>>
>>
> Frankly, I am sick and tired of CRAM-MD5 track discussion and would
> rather talk about GS2 and SCRAM first. But the list looks good to me
> otherwise.

Ok, I will consider changing the order.  I hope that we can get some
productive discussion on-list about CRAM-MD5 before the meeting.  I
will send another message on this topic shortly.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6BFftW082009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 04:15:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6BFfUg082008; Thu, 6 Nov 2008 04:15:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6BFSax081997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 6 Nov 2008 04:15:40 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1Ky2pj-0007Lk-I1 for [e-mail]; Thu, 06 Nov 2008 12:15:27 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx4.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1Ky2pj-0000YG-B2 for [e-mail]; Thu, 06 Nov 2008 12:15:27 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1Ky2pj-0007Wf-3q for [e-mail]; Thu, 06 Nov 2008 12:15:27 +0100
From: Hallvard B Furuseth <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 6 Nov 2008 12:15:27 +0100
To: [e-mail]
Subject: Re: SASL WG status, 11/5
In-Reply-To: <[e-mail]>
References: <[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, MISSING_SUBJECT=0.001,NO_RECEIVED=-0.001,UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: C0C7BFCE96701952E5E4F9511E794ACB669397AC
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1195 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>

Tom Yu writes:
> SCRAM:
>   * LDAP storage of auth info
>         - WG to consider draft-melnikov-sasl-scram-ldap-00

Why not authPassword from RFC 3112?  Value something like
   scram-hmac-sha1$<iter-count>:<salt>$<stored-key>:<server-key>
or scram-hmac-sha1-<iter-count>$<salt>$<stored-key>:<server-key>
where salt and keys are base64-encoded.

For that matter, I've missed why this is a SASL draft instead
of an ldapext draft.  Proof of concept for SCRAM, maybe?

-- 
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 mA6ARBaJ078917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 03:27:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6ARBsa078916; Thu, 6 Nov 2008 03:27:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6ARAxG078909 for <[e-mail]>; Thu, 6 Nov 2008 03:27:10 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 6 Nov 2008 10:27:09 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 10:26:55 +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: Tom Yu <[e-mail]>
CC: [e-mail]
Subject: Re: draft agenda IETF73 SASL WG session
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>

Tom Yu wrote:

>Also uploaded to meeting materials site.  Please comment if you would
>like to add things to the agenda.
>
>Simple Authentication And Security Layer (SASL)
>IETF73, Minneapolis, MN
>
>Tuesday, November 18, 2008 at 1300-1500
>=======================================
>
>Chairs:
>
>Tom Yu <[e-mail]>
>Kurt Zeilenga <[e-mail]>
>
>DRAFT AGENDA: (2 hours)
>
>* intro, scribe appointment, agenda bashing - 5 min
>
>* document status - 5 min
>  - draft-ietf-sasl-4422bis-00
>  - draft-ietf-sasl-crammd5-10
>  - draft-ietf-sasl-digest-to-historic-00
>  - draft-ietf-sasl-gs2-10
>  - draft-melnikov-sasl-scram-ldap-00
>  - draft-newman-auth-scram-06
>
>* CRAM-MD5 - 30 min
>  - fate of RFC 2195
>  - fate of CRAM-MD5 IANA registry entry
>  - track of draft-ietf-sasl-crammd5-10
>
>* other technical discussion - 60 min
>  - GS2
>  - SCRAM
>  - interop report
>  
>
Frankly, I am sick and tired of CRAM-MD5 track discussion and would 
rather talk about GS2 and SCRAM first. But the list looks good to me 
otherwise.

>* discuss milestones - 10 min
>
>* open microphone - remaining time
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6AOrAN078786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2008 03:24:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA6AOr9P078785; Thu, 6 Nov 2008 03:24:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA6AOfUl078740 for <[e-mail]>; Thu, 6 Nov 2008 03:24:53 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 6 Nov 2008 10:24:39 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Thu, 06 Nov 2008 10:24:26 +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: Tom Yu <[e-mail]>
CC: [e-mail]
Subject: Re: SASL WG status, 11/5
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>

Tom Yu wrote:

>SCRAM:
>  * PBKDF2 iteration counts - DONE (Alexey)
>  
>
Yes, the new draft wasn't posted before the deadline, but the change is 
done.

>  * channel binding - Nico?
>  
>
I think this is done as well. Nico said that the current text is Ok.

>  * LDAP storage of auth info
>        - WG to consider draft-melnikov-sasl-scram-ldap-00
>  
>
Yes, indeed.
I wasn't sure if the format proposed in the draft was reasonable and I 
didn't have time to consult with Kurt or anybody else. We can quickly 
discuss this in Minneapolis.

>  * make equivalent to a GS2 mech
>        - pending WG discussion of encoding issue?
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5Mngcs035414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 15:49:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA5MngWW035413; Wed, 5 Nov 2008 15:49:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 mA5Mne1s035404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 5 Nov 2008 15:49:41 -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 mA5Mnd4S028388 for <[e-mail]>; Wed, 5 Nov 2008 17:49:39 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mA5MncUj021776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 5 Nov 2008 17:49:39 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mA5MnclL023333; Wed, 5 Nov 2008 17:49:38 -0500 (EST)
To: [e-mail]
Subject: draft agenda IETF73 SASL WG session
From: Tom Yu <[e-mail]>
Date: Wed, 05 Nov 2008 17:49:38 -0500
Message-ID: <[e-mail]>
Lines: 39
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>

Also uploaded to meeting materials site.  Please comment if you would
like to add things to the agenda.

Simple Authentication And Security Layer (SASL)
IETF73, Minneapolis, MN

Tuesday, November 18, 2008 at 1300-1500
=======================================

Chairs:

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

DRAFT AGENDA: (2 hours)

* intro, scribe appointment, agenda bashing - 5 min

* document status - 5 min
  - draft-ietf-sasl-4422bis-00
  - draft-ietf-sasl-crammd5-10
  - draft-ietf-sasl-digest-to-historic-00
  - draft-ietf-sasl-gs2-10
  - draft-melnikov-sasl-scram-ldap-00
  - draft-newman-auth-scram-06

* CRAM-MD5 - 30 min
  - fate of RFC 2195
  - fate of CRAM-MD5 IANA registry entry
  - track of draft-ietf-sasl-crammd5-10

* other technical discussion - 60 min
  - GS2
  - SCRAM
  - interop report

* discuss milestones - 10 min

* open microphone - remaining time



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA5Mm3DQ035324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Nov 2008 15:48:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA5Mm36U035323; Wed, 5 Nov 2008 15:48:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 mA5MlpjW035309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 5 Nov 2008 15:48:02 -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 mA5MlnK5027249 for <[e-mail]>; Wed, 5 Nov 2008 17:47:50 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as [e-mail]) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id mA5MlmOU021197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 5 Nov 2008 17:47:49 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id mA5Mlm8A023311; Wed, 5 Nov 2008 17:47:48 -0500 (EST)
To: [e-mail]
Subject: SASL WG status, 11/5
From: Tom Yu <[e-mail]>
Date: Wed, 05 Nov 2008 17:47:48 -0500
Message-ID: <[e-mail]>
Lines: 28
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>

WG Charter - DONE

IETF73 draft WG agenda - Tom - 11/5 - DONE

IETF73 final WG agenda - Tom - 11/10

RFC 4422bis - review needed - WG

RFC 4422 implementation reports - Kurt - past due

RFC 4013bis - dropped from WG

CRAM-MD5 - resolve pending items from Frank:
  * adding Simon's PLAIN/CRAM comparison
  * tying to saslprep revision - N/A due to saslprep puntage
  * resolution on intended track - WG

digest-to-historic - mostly done, awaiting SCRAM

GS2 - Awaiting SCRAM issue resolution (encoding)

SCRAM:
  * PBKDF2 iteration counts - DONE (Alexey)
  * channel binding - Nico?
  * LDAP storage of auth info
        - WG to consider draft-melnikov-sasl-scram-ldap-00
  * make equivalent to a GS2 mech
        - pending WG discussion of encoding issue?