Re: ABNF for the three cases of SCRAM as GS2

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

Alexey Melnikov wrote:
>Hallvard B Furuseth wrote:
>>> 1.1. Terminology
>>>   Some clarifications and additional definitions follow:   
>>>
>> What's a server-authorized proxy?
>
> An entity authorized by the server to act on its behalf. I am not sure
> this needs to be spelled out?

To clarify my request for clarification, I'm not sure what these points
in the intro are saying, even with your explanation:

    - The server does not gain the ability to impersonate the client to
      other servers (with an exception for server-authorized proxies).

    - The mechanism permits the use of a server-authorized proxy without
      requiring that proxy to have super-user rights with the back-end
      server.

Where does this proxy sit, and how does this proxy auth work?  If both
server and proxy needs to see the scram-auth the user, I assume that
would break if the channel binding field is present.  If they don't,
then one trusts the other to tell it the user's identity, which I
suppose is what you mean by super-user privileges.  Or can one of them
watch the auth performed by the other, and verify that it is valid?

Unless the draft is just saying that SCRAM supports the SASL
authorization identity field and servers must do some internal auth
magic to make use of that.

>> Also, how does an iteration count of more than 1 help on a site where
>> passwords are stored in several forms anyway, maybe including salted MD5
>> for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)
>
> My understanding is that one can read values from hashed password files
> and use them to implement server side SCRAM.
> There is no requirement that SCRAM specific hash be stored in such files.

That sounds strange, unless you are talking about a weakness which can
be attacked.

The password-file secret would be
  salt, Hash(salt || password)
while even with iteration count 0, SCRAM SaltedPassword is
  Hash((password XOR opad) || Hash((password XOR ipad) || salt || INT(1)))

In any case, if there is a mapping MD5 crypt -> SCRAM crypt, that just
makes the iteration count less useful as far as I can see.

-- 
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 n0VLCZaJ058515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:12:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VLCZ9B058514; Sat, 31 Jan 2009 14:12:35 -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 n0VLCMmB058482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 31 Jan 2009 14:12:34 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LTN8X-00035u-Qr; Sat, 31 Jan 2009 22:12:21 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LTN8X-0004gg-J9; Sat, 31 Jan 2009 22:12:21 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LTN8X-0000qC-Al; Sat, 31 Jan 2009 22:12:21 +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: Sat, 31 Jan 2009 22:12:21 +0100
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 7B87E9E412763C1CC388E4B081AE21A588DF108C
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1361 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>

Alexey Melnikov wrote:
>Hallvard B Furuseth wrote:
>>> 1.1. Terminology
>>>   Some clarifications and additional definitions follow:   
>>>
>> What's a server-authorized proxy?
>
> An entity authorized by the server to act on its behalf. I am not sure
> this needs to be spelled out?

To clarify my request for clarification, I'm not sure what these points
in the intro are saying, even with your explanation:

    - The server does not gain the ability to impersonate the client to
      other servers (with an exception for server-authorized proxies).

    - The mechanism permits the use of a server-authorized proxy without
      requiring that proxy to have super-user rights with the back-end
      server.

Where does this proxy sit, and how does this proxy auth work?  If both
server and proxy needs to see the scram-auth the user, I assume that
would break if the channel binding field is present.  If they don't,
then one trusts the other to tell it the user's identity, which I
suppose is what you mean by super-user privileges.  Or can one of them
watch the auth performed by the other, and verify that it is valid?

Unless the draft is just saying that SCRAM supports the SASL
authorization identity field and servers must do some internal auth
magic to make use of that.

>> Also, how does an iteration count of more than 1 help on a site where
>> passwords are stored in several forms anyway, maybe including salted MD5
>> for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)
>
> My understanding is that one can read values from hashed password files
> and use them to implement server side SCRAM.
> There is no requirement that SCRAM specific hash be stored in such files.

That sounds strange, unless you are talking about a weakness which can
be attacked.

The password-file secret would be
  salt, Hash(salt || password)
while even with iteration count 0, SCRAM SaltedPassword is
  Hash((password XOR opad) || Hash((password XOR ipad) || salt || INT(1)))

In any case, if there is a mapping MD5 crypt -> SCRAM crypt, that just
makes the iteration count less useful as far as I can see.

-- 
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 n0VCnQwY039418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 05:49:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VCnQZU039417; Sat, 31 Jan 2009 05:49:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VCnOAV039410 for <[e-mail]>; Sat, 31 Jan 2009 05:49:25 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.46.168] (92.40.46.168.sub.mbb.three.co.uk [92.40.46.168])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 31 Jan 2009 12:49:22 +0000
Message-ID: <[e-mail]>
Date: Sat, 31 Jan 2009 12:48:41 +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: Hallvard B Furuseth <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:
>  
>
 [...]

>>Arguably if p= moves to the front of the 
>>final-client-message-without-proof, then the has would still be easy to 
>>extract, but it would require extra memcopy, or some other thing.
>>    
>>
>Yes, the trade-off is whether it should be easy to parse or easy to
>construct.  Generally parsing is the less trivial and thus most
>bug-prone task, which is why I suggested putting it at the front.
>
>BTW, this is also why I like the grammar with fixed placement of
>fields.  Even if it seems simple enough, IIRC the opposite approach
>was one of the sources of bugs people mentioned for DIGEST-MD5.
>  
>
Yes, this is a good point.
(Note, that despite that I haven't made my own decision yet)

>>>Then the client immediately knows where to find it, and it can happily
>>>ignore all fields from optional extensions to the end of the message.
>>>      
>>>
>>I am not sure it buys that much. Other opinions?    
>>
>I just came up with one myself: One could not compute ClientSignature
>and ServerSignature while sending the message, so one must construct the
>entire message in memory before sending.  Not sure how much of an
>objection that is though.
>  
>
I don't think this matters even for small devices, as SCRAM messages are 
not going to be big.
What is more important is to allow for easy/fast implementations, for 
example to allow a single buffer to be used.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VCjOat039216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 05:45:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VCjO0f039215; Sat, 31 Jan 2009 05:45:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VCjN6x039208 for <[e-mail]>; Sat, 31 Jan 2009 05:45:23 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.46.168] (92.40.46.168.sub.mbb.three.co.uk [92.40.46.168])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 31 Jan 2009 12:45:22 +0000
Message-ID: <[e-mail]>
Date: Sat, 31 Jan 2009 12:44:43 +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: Hallvard B Furuseth <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Hallvard B Furuseth wrote:
>
>> Could you describe a practical example of how you imagine this field
>> being defined and used, presumably with one RFC defining it and two
>> others using it?  Even if you don't want this in the spec, it'd be nice
>> to be sure we are somewhere on the same page in this discussion.  So far
>> we apparently haven't been.
>
> Well, if this help you understand: one possibility is to define "m" as 
> containing a list of other attribute that are mandatory.
> I.e. if m=xy, then understanding of x=foo and y=bar by the other end 
> would be required to succeed.

To continue this example: m=xy would be the same as m=yx and I also 
think we should say that the order of extension attributes can be arbitrary.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VCfuqp039011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 05:41:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VCfuN2039010; Sat, 31 Jan 2009 05:41:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VCftLV039004 for <[e-mail]>; Sat, 31 Jan 2009 05:41:56 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.46.168] (92.40.46.168.sub.mbb.three.co.uk [92.40.46.168])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 31 Jan 2009 12:41:52 +0000
Message-ID: <[e-mail]>
Date: Sat, 31 Jan 2009 12:41:10 +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: Hallvard B Furuseth <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth wrote:

>Alexey Melnikov writes: 
>
>>Hallvard B Furuseth wrote:
>>
 [...]

>>>But now you need to specify that this
>>>is how the field is expected to be updated.  Not necessarily in that
>>>seciont, could go in an appendix.
>>>      
>>>
>>Can you please recommend specific text for consideration?
>>    
>>
>But I just did, roughly, and Jeffrey said "no no".  That was my second
>attemt too.  My first was the SCRAM "mandatory extensions"? thread,
>wich was a total misunderstanding of what was meant.
>
>But I can make another attempt, stealing a bit from later messages in
>this thread:
>
>* Rename the field and grammar symbol from "mandatory extensions" and
>  "mandatory-exts" to "reserved".
>  
>
I've used "reserved-mext", because "reserved" is an overloaded ABNF 
non-terminal name.

>* description:
>    - m: This attribute is reserved for future extensibility.
>      In this version of SCRAM, its presence in a client or a server
>      message MUST cause authentication failure when the attribute is
>      parsed by the other end.
>
Done.

>>>>>Hold on.  I think that's a bug anyway.  The draft should say that auth
>>>>>MUST be aborted if a message doesn't match the grammar in Section 6.
>>>>>          
>>>>>
>>>>No, we've been over this, and the consensus was that extension fields 
>>>>should be non-critical; that is, unrecognized extensions are ignored.
>>>>
>>>Not _mandatory_ extensions, since an older SASL implementation will
>>>abort the authentication when it sees "m=".
>>>      
>>>
>>I don't understand this comment.
>>    
>>
>Nor do I understand Jeffrey's.  We were discussing mandatory extensions,
>"m=" or a replacement for it.  This cannot be ignored, it'll cause a
>failure in the current implementation.
>
Correct.

>So how does that square with
>"unrecognized extensions are ignored"?
>
"Unrecognized extension attributes", i.e. attributes not defined in the 
draft (the inside of <extensions> ABNF production), MUST be ignored.
The m= attribute is not unrecognized, as it is defined (even though 
without a syntax ;-)).

>That's the optional extensions
>field in the draft.  Unless the draft is saying something quite else
>than people agreed off-line that it should say - and I'm talking about
>the draft while he's talking about that off-line agreement.
>  
>
>>Any optional extension goes at the end. 
>>Any mandatory extension would result in m= being present and can put 
>>something at the end.
>>    
>>
>Yes.  Or, I assumed, it could have m=something present and not put
>something at the end.
>
That is another possibility, yes.

>Or it could have an optional extensions without
>"m=" at the front.
>  
>
We can always do that too, assuming the draft is updated to say that 
unrecognized attributes in unexpected places (such as at the front) MUST 
be ignored.
(Please note that I don't think we have consensus on this change just yet)

>But this was an approach I had not thought of.  You mean something like,
>an RFC puts the actual extension data ",x=foo" at the end, and "m=x," at
>the front to tell SCRAM that this particular "x=foo" extension cannot be
>ignored?  
>
Yes!

>But again, that's just another way to spell out a critical x= extension,
>so I don't see how it squares with "consensus was that extension fields
>should be non-critical" as an objection to another way to spell out
>mandatory extensions.
>
>Could you describe a practical example of how you imagine this field
>being defined and used, presumably with one RFC defining it and two
>others using it?  Even if you don't want this in the spec, it'd be nice
>to be sure we are somewhere on the same page in this discussion.  So far
>we apparently haven't been.
>  
>
Well, if this help you understand: one possibility is to define "m" as 
containing a list of other attribute that are mandatory.
I.e. if m=xy, then understanding of x=foo and y=bar by the other end 
would be required to succeed.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VC1TR2037660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 05:01:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VC1TC4037659; Sat, 31 Jan 2009 05:01:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VC1SiB037653 for <[e-mail]>; Sat, 31 Jan 2009 05:01:29 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.46.168] (92.40.46.168.sub.mbb.three.co.uk [92.40.46.168])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 31 Jan 2009 12:01:27 +0000
Message-ID: <[e-mail]>
Date: Sat, 31 Jan 2009 12:00:49 +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: Hallvard B Furuseth <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> --On Tuesday, January 27, 2009 07:00:55 PM +0100 Hallvard B Furuseth 
> <[e-mail]> wrote:

 [...]

>> Define "correctly".  Generate some unneeded SCRAM hashes for each
>> password and store them somewhere safe, in anticipation of the day
>> when we'll decide to add some extra servers?  Or ask all users to
>> change passwords because we've added another LDAP server or whatever?
>
> if you have a bunch of mirror servers providing the same service, 
> there's really no reason _not_ to use the same salt on all of them.  
> There's no reason for one LDAP server to impersonate a user to another 
> in the same pool.  Put another way, you may have multiple machines, 
> but they are providing the same _service_.

Agreed.

> SCRAM is suited to small environments where it's reasonable to 
> maintain separate authentication databases for every service, usually 
> because there is no central infrastructure.  If you're trying to set 
> up enterprise-grade distributed infrastructure, you should start with 
> an enterprise-grade authentication service.
>
>> I agree that by itself, the point belongs in Security Considerations.
>> My objection is that this point in the Introduction, standing alone, is
>> simply false:
>>
>>     - The server does not gain the ability to impersonate the client to
>>       other servers (with an exception for server-authorized proxies).
>
> Hm.  Maybe.

Hallvard, can you please recommend specific changes to the document?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VBwWlY037539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 04:58:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VBwWBF037538; Sat, 31 Jan 2009 04:58:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VBwVjG037532 for <[e-mail]>; Sat, 31 Jan 2009 04:58:32 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.46.168] (92.40.46.168.sub.mbb.three.co.uk [92.40.46.168])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 31 Jan 2009 11:58:28 +0000
Message-ID: <[e-mail]>
Date: Sat, 31 Jan 2009 11:57:51 +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: Hallvard B Furuseth <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth wrote:

>[I should have changed the subject.  Better late than nenver...]
>
>Jeffrey Hutzelman writes:
>  
>
 [...]

>>>>1.2. Notation
>>>>   U0   := HMAC(str, salt || INT(1))
>>>>
>>>Make that HMAC(str, (salt || INT(1))) or HMAC((str, salt) || INT(1)).      
>>>
>>Uh, why?  It's pretty clear than an HMAC requires two arguments (key and 
>>message); in fact, that's about three paragraphs above the text you quote. 
>>    
>>
>
>Nothing important.  Just a bit easier to read.  Or rather, to glance at
>without needing to read as far as three paragraphs away.
>
I actually disagree that adding extra () would add clarity in this case. 
Besides, I was reusing a concention defined in another RFC.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VBskn0037028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 04:54:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VBskDu037027; Sat, 31 Jan 2009 04:54:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VBsX5i037014 for <[e-mail]>; Sat, 31 Jan 2009 04:54:44 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.46.168] (92.40.46.168.sub.mbb.three.co.uk [92.40.46.168])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 31 Jan 2009 11:54:30 +0000
Message-ID: <[e-mail]>
Date: Sat, 31 Jan 2009 11:53:46 +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: Hallvard B Furuseth <[e-mail]>
CC: [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth wrote:

>Alexey Melnikov writes:  
>
>>To clarify: I will produce both the updated (hopefully final) version
>>of SCRAM without GS2-related changes, plus another version which
>>contains GS2 related ABNF and examples.    
>>
>Likely not final.
>
I meant in the sense that it would be good enough for the WGLC.

>Then your first versions of the "To be written"
>appendixes woudl have to pass through with almost no discussion.
>
>I've been waiting for a more finalized draft (by now, in particular
>Appendix B) before doing a careful review, and reposting some concerns
>of mine in case the authors just hadn't gotten to them yet.  Appendix B
>to possibly short-circuit discussion of some other details.  But I can
>look through the archives and my notes and (re-)post, if you want.
>  
>
Yes please.
Please don't mention the description of m= again, I will take care of 
that. Actually, you might hold off till I posted an updated version.

>Some old and new points I remember off-hand:
>
>- Regarding GS2, let me just make a general protest againt the verbose
>  way the derivation of GS2 names are spelled out in... I don't remember
>  which mechanism draft(s) at the moment.  Just say it has
>
>   "GSS-API mechanism OID: <whatever>
>    SASL mechanism name: GS2-<whatever> due to [GS2] section 3)"
>  
>
Yes, absolutely.

 [...]

>>1.1. Terminology
>>   Some clarifications and additional definitions follow:    
>>
>What's a server-authorized proxy?
>  
>
An entity authorized by the server to act on its behalf. I am not sure 
this needs to be spelled out?
 [...]

>>5. SCRAM Authentication Exchange
>>   Servers SHOULD announce a hash iteration-count of at least 128.    
>>
>Why?  Different hash algorithms have different strengths and different
>costs to compute, thus I'd think this depends on the hash algorithm.
>  
>
Yes, I agree with that.
So I've moved this sentence to the section talking about various SCRAM 
attributes and reworded it as:
    For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash 
iteration-count
    of at least 128.

>And, for that matter, on the strength of expected attacks.
>  
>
This is just a minimal requirement, deployments can choose bigger 
values, or, if there is a good reason, smaller values.
I would be happy with having any value that the Security Directorate 
would recommend for HMAC-SHA-1.

>Also, how does an iteration count of more than 1 help on a site where
>passwords are stored in several forms anyway, maybe including salted MD5
>for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)
>
My understanding is that one can read values from hashed password files 
and use them to implement server side SCRAM.
There is no requirement that SCRAM specific hash be stored in such files.

>If I remember correctly (and I may not), one problem with the proposed
>competing SRP mechanism was the computation cost.  How does that compare
>with a high SCRAM iteration count?
>  
>
I think some tests need to be performed before I can answer this question.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SGAhXP056389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 09:10:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SGAh14056388; Wed, 28 Jan 2009 09:10:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SGAV9j056356 for <[e-mail]>; Wed, 28 Jan 2009 09:10:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.176] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SYCDdgB0lJ9=@rufus.isode.com>; Wed, 28 Jan 2009 16:10:31 +0000
Message-ID: <[e-mail]>
Date: Wed, 28 Jan 2009 16:10:01 +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: Jeffrey Hutzelman <[e-mail]>
CC: Hallvard B Furuseth <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> --On Wednesday, January 28, 2009 03:01:58 PM +0100 Hallvard B Furuseth 
> <[e-mail]> wrote:
>
>> The second is a set of RCFs which an implementation may pick and
>> choose from.  This is what I understand with the word "extension".
>> An implementation of the 4rd RFC need not even know about the 2nd
>> and 3rd, except it must know from the 2nd what to do about "m=".
>>
>> The first is an ordered sequence of RFCs, each adding to/replacing the
>> previous one.  An implementation of the 4rd RFC will known about the 2nd
>> and 3rd, though it might just know enough to recognize and reject any
>> real use of them if that should be necessary.  If this is what you are
>> talking about, then don't call it "extensions" at all.
>
> Yes, that's a pretty good description of the distinction I was going 
> for. The m= field is intended to be a reserved field whose semantics 
> will be defined by a future protocol update.  The _expectation_ is 
> that said update will define semantics which make it possible for 
> "extensions" to have critical/mandatory fields.  Likely the value of 
> m= will turn out to be a list of names of other extension fields which 
> are also mandatory, but we haven't actually said that, and a large 
> part of the point is to avoid having to nail that down and say it 
> right now.
>
> FWIW, I think it's likely that the first time we have an extension 
> which needs a mandatory field, we'll do it in a single document which 
> both revises the spec to define how the m= field works _and_ adds an 
> extension, which I think you allude to above.

Agreed.

> If you think it's confusing to use the name "mandatory-exts" for the 
> nonterminal describing the "m=" field, it could be changed.  I think 
> the name is intended to be interpreted in the same vein as the others 
> around it; "m=" isn't itself a mandatory extension any more than "n=" 
> is a username.  Rather, "m=" contains the list of mandatory extensions 
> just as "n=" contains the username.
>
>>>> But now you need to specify that this
>>>> is how the field is expected to be updated.  Not necessarily in that
>>>> seciont, could go in an appendix.
>>>
>>> Can you please recommend specific text for consideration?
>>
>> But I just did, roughly, and Jeffrey said "no no".  That was my second
>> attemt too.
>
> I think we're converging.

It finally looks like that to me too :-).

>>  My first was the SCRAM "mandatory extensions"? thread,
>> wich was a total misunderstanding of what was meant.
>>
>> But I can make another attempt, stealing a bit from later messages in
>> this thread:
>>
>> * Rename the field and grammar symbol from "mandatory extensions" and
>>   "mandatory-exts" to "reserved".
>>
>> * description:
>>     - m: This attribute is reserved for future extensibility.
>>       In this version of SCRAM, its presence in a client or a server
>>       message MUST cause authentication failure when the attribute is
>>       parsed by the other end.
>
> Sounds reasonable to me.

That is fine with me as well.

>>>>>> Hold on.  I think that's a bug anyway.  The draft should say that 
>>>>>> auth
>>>>>> MUST be aborted if a message doesn't match the grammar in Section 6.
>>>>>>
>>>>> No, we've been over this, and the consensus was that extension fields
>>>>> should be non-critical; that is, unrecognized extensions are ignored.
>>>>
> Nevermind this.  I misinterpreted you; I thought you were suggesting 
> that all unrecognized fields should be rejected, right after we 
> updated the document to make it clear that they are allowed.
>
> Read strictly, the grammar only admits unrecognized fields at the end 
> of each of several messages, and unrecognized fields elsewhere are 
> invalid.

Right.

> I think we need to be much more clear on this point.  If we want to 
> require attributes to be in a particular order, then we need to say 
> that the sender MUST put them in that order.  If we are going to make 
> use of this fact to put critical extensions at the front, then we also 
> need to say that the recipient MUST reject messages where they are not 
> in order.

Ok, this sound reasonable.
But let me think a bit more about ordering.

> I'd much rather stick with m= as the indicator for critical 
> extensions, and allow receivers to accept messages with the attributes 
> in any order. Interoperability is better served by "be strict in what 
> you send, and liberal in what you accept" than by "be strict in what 
> you send and in what you accept".




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SEVZv3050272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 07:31:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SEVZ1J050271; Wed, 28 Jan 2009 07:31:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SEVNAD050256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 28 Jan 2009 07:31:34 -0700 (MST) (envelope-from [e-mail])
Received: from 173-114-124-216.pools.spcsdns.net (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0SEVJDw015903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 09:31:20 -0500 (EST)
Date: Wed, 28 Jan 2009 09:31:19 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: SCRAM notes
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, January 28, 2009 03:01:58 PM +0100 Hallvard B Furuseth 
<[e-mail]> wrote:

> The second is a set of RCFs which an implementation may pick and
> choose from.  This is what I understand with the word "extension".
> An implementation of the 4rd RFC need not even know about the 2nd
> and 3rd, except it must know from the 2nd what to do about "m=".
>
> The first is an ordered sequence of RFCs, each adding to/replacing the
> previous one.  An implementation of the 4rd RFC will known about the 2nd
> and 3rd, though it might just know enough to recognize and reject any
> real use of them if that should be necessary.  If this is what you are
> talking about, then don't call it "extensions" at all.

Yes, that's a pretty good description of the distinction I was going for. 
The m= field is intended to be a reserved field whose semantics will be 
defined by a future protocol update.  The _expectation_ is that said update 
will define semantics which make it possible for "extensions" to have 
critical/mandatory fields.  Likely the value of m= will turn out to be a 
list of names of other extension fields which are also mandatory, but we 
haven't actually said that, and a large part of the point is to avoid 
having to nail that down and say it right now.

FWIW, I think it's likely that the first time we have an extension which 
needs a mandatory field, we'll do it in a single document which both 
revises the spec to define how the m= field works _and_ adds an extension, 
which I think you allude to above.


If you think it's confusing to use the name "mandatory-exts" for the 
nonterminal describing the "m=" field, it could be changed.  I think the 
name is intended to be interpreted in the same vein as the others around 
it; "m=" isn't itself a mandatory extension any more than "n=" is a 
username.  Rather, "m=" contains the list of mandatory extensions just as 
"n=" contains the username.



>>> But now you need to specify that this
>>> is how the field is expected to be updated.  Not necessarily in that
>>> seciont, could go in an appendix.
>>
>> Can you please recommend specific text for consideration?
>
> But I just did, roughly, and Jeffrey said "no no".  That was my second
> attemt too.

I think we're converging.

>  My first was the SCRAM "mandatory extensions"? thread,
> wich was a total misunderstanding of what was meant.
>
> But I can make another attempt, stealing a bit from later messages in
> this thread:
>
> * Rename the field and grammar symbol from "mandatory extensions" and
>   "mandatory-exts" to "reserved".
>
> * description:
>     - m: This attribute is reserved for future extensibility.
>       In this version of SCRAM, its presence in a client or a server
>       message MUST cause authentication failure when the attribute is
>       parsed by the other end.

Sounds reasonable to me.




>>>>> Hold on.  I think that's a bug anyway.  The draft should say that auth
>>>>> MUST be aborted if a message doesn't match the grammar in Section 6.
>>>>>
>>>> No, we've been over this, and the consensus was that extension fields
>>>> should be non-critical; that is, unrecognized extensions are ignored.

Nevermind this.  I misinterpreted you; I thought you were suggesting that 
all unrecognized fields should be rejected, right after we updated the 
document to make it clear that they are allowed.

Read strictly, the grammar only admits unrecognized fields at the end of 
each of several messages, and unrecognized fields elsewhere are invalid.

I think we need to be much more clear on this point.  If we want to require 
attributes to be in a particular order, then we need to say that the sender 
MUST put them in that order.  If we are going to make use of this fact to 
put critical extensions at the front, then we also need to say that the 
recipient MUST reject messages where they are not in order.  I'd much 
rather stick with m= as the indicator for critical extensions, and allow 
receivers to accept messages with the attributes in any order. 
Interoperability is better served by "be strict in what you send, and 
liberal in what you accept" than by "be strict in what you send and in what 
you accept".


> I just came up with one myself: One could not compute ClientSignature
> and ServerSignature while sending the message, so one must construct the
> entire message in memory before sending.  Not sure how much of an
> objection that is though.

I don't think it's a significant one, given the sizes of the messages 
involved.  That said, it seems somehow more aesthetically pleasing to me to 
keep it at the end.  Whatever.


-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SEOJc3049798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 07:24:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SEOJKW049797; Wed, 28 Jan 2009 07:24:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n0SEOGUX049791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 28 Jan 2009 07:24:18 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LSBKv-0004wv-Kp; Wed, 28 Jan 2009 15:24:13 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx5.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LSBKu-0000Rn-V7; Wed, 28 Jan 2009 15:24:13 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LSBKu-0001OW-Tw; Wed, 28 Jan 2009 15:24:12 +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: Wed, 28 Jan 2009 15:24:12 +0100
To: Alexey Melnikov <[e-mail]>
cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: E1F48013997FD9749F1A0DC61D096FA282475A52
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 1353 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 wrote:
> >>That sounds unproblematic if you are talking about a newer version of
> >>the spec which "obsoletes" this one rather than one of several
> >>extensions which "updates" it.
> >>
> > What is the practical difference?
> 
> As Jeffrey pointed out, I've been conflating the RFC process with the
> the meaning of what a new RFC does to an old one.  However, about
> mandatory extensions (as opposed to the optional ones at the end):

Argh...  no, not mandatory vs. optional extensions.
 
> The second

that is, what I called "updating" SCRAM

> is a set of RCFs which an implementation may pick and
> choose from.  This is what I understand with the word "extension".
> An implementation of the 4rd RFC need not even know about the 2nd
> and 3rd, except it must know from the 2nd what to do about "m=".
> 
> The first

I.e. "obsoleting" SCRAM

> is an ordered sequence of RFCs, each adding to/replacing the
> previous one.  An implementation of the 4rd RFC will known about the 2nd
> and 3rd, though it might just know enough to recognize and reject any
> real use of them if that should be necessary.  If this is what you are
> talking about, then don't call it "extensions" at all.

-- 
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 n0SE2GoC048751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 07:02:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SE2G0j048750; Wed, 28 Jan 2009 07:02:16 -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 n0SE21lu048738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 28 Jan 2009 07:02:14 -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 1LSAzP-0005Fm-98; Wed, 28 Jan 2009 15:01:59 +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 1LSAzO-0000x2-Uq; Wed, 28 Jan 2009 15:01:59 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LSAzO-0001Iz-9y; Wed, 28 Jan 2009 15:01:58 +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: Wed, 28 Jan 2009 15:01:58 +0100
To: Alexey Melnikov <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 6791B8E32DC011084A7101A0B9C63F336AF6606B
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1352 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>

Alexey Melnikov writes:
>Hallvard B Furuseth wrote:
>>But isn't that what I just said?  Except if we are talking of *a* newer
>>version of the spec, I think calling it "extensions" is a misnomer.
>>Should be something about "reserved" instead.
>
> In my copy I have the following text:
> 
> - 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.
> 
> I think this is quite clear.

I thought so too, but apparently I've gotten it wrong several times now
- even after Jeffrey's explanations...

>>>This is not (yet) an extensibility mechanism; it's a field reserved
>>>for use by a later version of the spec.
>>>    
>>That sounds unproblematic if you are talking about a newer version of
>>the spec which "obsoletes" this one rather than one of several
>>extensions which "updates" it.
>>
> What is the practical difference?

As Jeffrey pointed out, I've been conflating the RFC process with the
the meaning of what a new RFC does to an old one.  However, about
mandatory extensions (as opposed to the optional ones at the end):

The second is a set of RCFs which an implementation may pick and
choose from.  This is what I understand with the word "extension".
An implementation of the 4rd RFC need not even know about the 2nd
and 3rd, except it must know from the 2nd what to do about "m=".

The first is an ordered sequence of RFCs, each adding to/replacing the
previous one.  An implementation of the 4rd RFC will known about the 2nd
and 3rd, though it might just know enough to recognize and reject any
real use of them if that should be necessary.  If this is what you are
talking about, then don't call it "extensions" at all.

>>But now you need to specify that this
>>is how the field is expected to be updated.  Not necessarily in that
>>seciont, could go in an appendix.
>
> Can you please recommend specific text for consideration?

But I just did, roughly, and Jeffrey said "no no".  That was my second
attemt too.  My first was the SCRAM "mandatory extensions"? thread,
wich was a total misunderstanding of what was meant.

But I can make another attempt, stealing a bit from later messages in
this thread:

* Rename the field and grammar symbol from "mandatory extensions" and
  "mandatory-exts" to "reserved".

* description:
    - m: This attribute is reserved for future extensibility.
      In this version of SCRAM, its presence in a client or a server
      message MUST cause authentication failure when the attribute is
      parsed by the other end.

>>>>Hold on.  I think that's a bug anyway.  The draft should say that auth
>>>>MUST be aborted if a message doesn't match the grammar in Section 6.
>>>>
>>>No, we've been over this, and the consensus was that extension fields 
>>>should be non-critical; that is, unrecognized extensions are ignored.
>>>    
>>Not _mandatory_ extensions, since an older SASL implementation will
>>abort the authentication when it sees "m=".
>
> I don't understand this comment.

Nor do I understand Jeffrey's.  We were discussing mandatory extensions,
"m=" or a replacement for it.  This cannot be ignored, it'll cause a
failure in the current implementation.  So how does that square with
"unrecognized extensions are ignored"?  That's the optional extensions
field in the draft.  Unless the draft is saying something quite else
than people agreed off-line that it should say - and I'm talking about
the draft while he's talking about that off-line agreement.

> Any optional extension goes at the end. 
> Any mandatory extension would result in m= being present and can put 
> something at the end.

Yes.  Or, I assumed, it could have m=something present and not put
something at the end.  Or it could have an optional extensions without
"m=" at the front.

But this was an approach I had not thought of.  You mean something like,
an RFC puts the actual extension data ",x=foo" at the end, and "m=x," at
the front to tell SCRAM that this particular "x=foo" extension cannot be
ignored?

But again, that's just another way to spell out a critical x= extension,
so I don't see how it squares with "consensus was that extension fields
should be non-critical" as an objection to another way to spell out
mandatory extensions.

Could you describe a practical example of how you imagine this field
being defined and used, presumably with one RFC defining it and two
others using it?  Even if you don't want this in the spec, it'd be nice
to be sure we are somewhere on the same page in this discussion.  So far
we apparently haven't been.

> (...)
>>That's not what the grammar does.  It only allows optional extensions
>>at the end, except for the wart that "p=" comes after it in the final
>>client message.
>>
>>Maybe it'd be cleaner to put "p=" at the _front_ of that message?
>>  
> Not really. p= is constructed from:
> 
> AuthMessage     := client-first-message + "," +
>                    server-first-message + "," +
>                    final-client-message-without-proof
> 
> so it covers everything, including extensions.
> One can just strcat() 3 pieces together and calculate hash from them.

Yes...

> Arguably if p= moves to the front of the 
> final-client-message-without-proof, then the has would still be easy to 
> extract, but it would require extra memcopy, or some other thing.

Yes, the trade-off is whether it should be easy to parse or easy to
construct.  Generally parsing is the less trivial and thus most
bug-prone task, which is why I suggested putting it at the front.

BTW, this is also why I like the grammar with fixed placement of
fields.  Even if it seems simple enough, IIRC the opposite approach
was one of the sources of bugs people mentioned for DIGEST-MD5.

>>Then the client immediately knows where to find it, and it can happily
>>ignore all fields from optional extensions to the end of the message.
>>
> I am not sure it buys that much. Other opinions?

I just came up with one myself: One could not compute ClientSignature
and ServerSignature while sending the message, so one must construct the
entire message in memory before sending.  Not sure how much of an
objection that is though.

-- 
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 n0RNlEO6008491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 16:47:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RNlE5M008490; Tue, 27 Jan 2009 16:47:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RNlDI9008484 for <[e-mail]>; Tue, 27 Jan 2009 16:47:13 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.94.85] (92.40.94.85.sub.mbb.three.co.uk [92.40.94.85])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 27 Jan 2009 23:47:10 +0000
Message-ID: <[e-mail]>
Date: Tue, 27 Jan 2009 23:46:28 +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: Jeffrey Hutzelman <[e-mail]>
CC: Hallvard B Furuseth <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> --On Tuesday, January 27, 2009 10:38:34 PM +0000 Alexey Melnikov 
> <[e-mail]> wrote:
>
>> In my copy I have the following text:
>>
>> - 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.
>
> I'm not sure if I like the second sentence.  That's actually how I 
> expect this attribute to work, if/when we ever define it, but it would 
> be a mistake for any implementor to assume any particular syntax or 
> semantics, or for an extension to assume that it can include a 
> mandatory attribute under the current spec.

Ok, do you want it removed?

>>>> This is not (yet) an extensibility mechanism; it's a field reserved
>>>> for use by a later version of the spec.
>>>
>>> That sounds unproblematic if you are talking about a newer version of
>>> the spec which "obsoletes" this one rather than one of several
>>> extensions which "updates" it.
>>
>> What is the practical difference?
>
> Process-wise, the difference between "obsoletes" and "updates" is that 
> if one document "obsoletes" another, then it is no longer necessary to 
> refer to the older document, as the new one completely specifies the 
> new protocol.  If one document "updates" another, then it makes 
> changes which must be read together with the original document to be 
> meaningful.

I know the IETF meaning of these words. I was talking about 
implementors. In either case an implementor can find the original 
document using www.rfc-editor.org website.

> That's not the distinction we're actually talking about here.  We're 
> talking about the distinction between a document which revises the 
> base spec, by either updating or obsoleting the document we're 
> currently discussing, and a document which adds an extension using 
> some mechanism already provided for that purpose, such as by adding 
> new attributes in the places reserved in the protocol for that purpose.
>
> An updated version of the spec can make pretty much any change it 
> wants, though it is usually preferred to avoid making 
> backward-incompatible changes.  An extension adds to the spec only in 
> previously-defined ways.
>
> I believe we envisioned the m= field as something to be redefined by a 
> future revision to SCRAM.  In its present form, it cannot be used by 
> an extension which does not revise SCRAM.

I think you are talking about mechanics of how such hypothetical change 
can be made. I don't think we should care at the moment.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RN3quG006548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 16:03:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RN3q30006547; Tue, 27 Jan 2009 16:03:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RN3eXZ006535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 27 Jan 2009 16:03:51 -0700 (MST) (envelope-from [e-mail])
Received: from 173-114-124-216.pools.spcsdns.net (173-114-124-216.pools.spcsdns.net [173.114.124.216]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0RN3ZgT025770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 18:03:37 -0500 (EST)
Date: Tue, 27 Jan 2009 18:03:35 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Hallvard B Furuseth <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: SCRAM notes
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F>            <[e-mail]> <[e-mail]>            <[e-mail]> <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, January 27, 2009 10:38:34 PM +0000 Alexey Melnikov 
<[e-mail]> wrote:

> In my copy I have the following text:
>
> - 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.

I'm not sure if I like the second sentence.  That's actually how I expect 
this attribute to work, if/when we ever define it, but it would be a 
mistake for any implementor to assume any particular syntax or semantics, 
or for an extension to assume that it can include a mandatory attribute 
under the current spec.


>>> This is not (yet) an extensibility mechanism; it's a field reserved
>>> for use by a later version of the spec.
>>>
>>>
>> That sounds unproblematic if you are talking about a newer version of
>> the spec which "obsoletes" this one rather than one of several
>> extensions which "updates" it.
>>
> What is the practical difference?

Process-wise, the difference between "obsoletes" and "updates" is that if 
one document "obsoletes" another, then it is no longer necessary to refer 
to the older document, as the new one completely specifies the new 
protocol.  If one document "updates" another, then it makes changes which 
must be read together with the original document to be meaningful.

That's not the distinction we're actually talking about here.  We're 
talking about the distinction between a document which revises the base 
spec, by either updating or obsoleting the document we're currently 
discussing, and a document which adds an extension using some mechanism 
already provided for that purpose, such as by adding new attributes in the 
places reserved in the protocol for that purpose.

An updated version of the spec can make pretty much any change it wants, 
though it is usually preferred to avoid making backward-incompatible 
changes.  An extension adds to the spec only in previously-defined ways.

I believe we envisioned the m= field as something to be redefined by a 
future revision to SCRAM.  In its present form, it cannot be used by an 
extension which does not revise SCRAM.



>> But now you need to specify that this
>> is how the field is expected to be updated.  Not necessarily in that
>> seciont, could go in an appendix.
>>
>>
> Can you please recommend specific text for consideration?

I don't think any text is required.  It's generally accepted that something 
which is unspecified or reserved is, well, unspecified or reserved, and 
also that a new document which revises an existing one can make more or 
less any change.  We're doing this the way we are specifically to _avoid_ 
having to specify anything about the m= field or how it will work.


>> I'm quite happy with a required order.  Easier to parse, and no need to
>> catch and hopefully fail on multiple occurrences of the same field name.

Recall the golden rule.  It's a well-understood principle that, when 
possible, we should be liberal in what we accept.  Anyone is free to 
produce an implementation that is strict about this, but as protocol 
designers, we would be foolish to assume that everyone will do so and to 
require it for correct operation of the protocol.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RMdDoo005797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 15:39:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RMdDMw005796; Tue, 27 Jan 2009 15:39:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RMdBul005790 for <[e-mail]>; Tue, 27 Jan 2009 15:39:12 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.94.85] (92.40.94.85.sub.mbb.three.co.uk [92.40.94.85])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 27 Jan 2009 22:39:09 +0000
Message-ID: <[e-mail]>
Date: Tue, 27 Jan 2009 22:38: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: Hallvard B Furuseth <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallvard B Furuseth wrote:

>Jeffrey Hutzelman writes:
>  
>
>>--On Tuesday, January 27, 2009 07:00:55 PM +0100 Hallvard B Furuseth 
>><[e-mail]> wrote:
>>    
>>
>>>    "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."
>>>
>>>Just add something amounting to "...except when it correctly matches an
>>>extension the implementation implements", and maybe some words from your
>>>description.  Then extension documents will no longer need to contradict
>>>the original description which says it MUST fail.
>>>      
>>>
>>No no.  The idea is that it MUST fail unless you are implementing a newer 
>>version of the spec which defines different behavior.
>>    
>>
>But isn't that what I just said?  Except if we are talking of *a* newer
>version of the spec, I think calling it "extensions" is a misnomer.
>Should be something about "reserved" instead.
>  
>
In my copy I have the following text:

- 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.

I think this is quite clear.

>>This is not (yet) an extensibility mechanism; it's a field reserved
>>for use by a later version of the spec.
>>    
>>
>That sounds unproblematic if you are talking about a newer version of
>the spec which "obsoletes" this one rather than one of several
>extensions which "updates" it.
>
What is the practical difference?

>But now you need to specify that this
>is how the field is expected to be updated.  Not necessarily in that
>seciont, could go in an appendix.
>  
>
Can you please recommend specific text for consideration?

>>>Hold on.  I think that's a bug anyway.  The draft should say that auth
>>>MUST be aborted if a message doesn't match the grammar in Section 6.
>>>      
>>>
>>No, we've been over this, and the consensus was that extension fields 
>>should be non-critical; that is, unrecognized extensions are ignored.
>>    
>>
>Not _mandatory_ extensions, since an older SASL implementation will
>abort the authentication when it sees "m=".
>  
>
I don't understand this comment. Any optional extension goes at the end. 
Any mandatory extension would result in m= being present and can put 
something at the end.

>>This is reflected by the grammar in section 6, which allows arbitrary
>>unrecognized name=value pairs in several places.
>>    
>>
>Only the optional extensions ("extensions" grammar symbol), which is at
>a fixed place in each message.
>  
>
>>>That will automatically support the 'm=' definition as it is described
>>>now, since an initial unknown field does not match the grammar..
>>>So the draft could support mandatory extensions just by saying extension
>>>documents should place them at the beginning.  And optional ones can
>>>stay at the end, where they are ignored when unrecognized.
>>>      
>>>
>>Hrm.  That's an interesting approach, and it might even work.  But I'm not 
>>really thrilled with the idea of making the order matter more than it 
>>already does.  The grammar currently describes fields in a particular 
>>order, but I would expect implementations to accept them in any order in 
>>practice, and depending on implementations _not_ to do so seems brittle. 
>>I'm much happier with an field whose criticality is indicated by its name 
>>rather than by its position.
>>    
>>
+1.

>I'm quite happy with a required order.  Easier to parse, and no need to
>catch and hopefully fail on multiple occurrences of the same field name.
>
>Admittedly order-dependent meaning of extension fields does make me
>nervous, but I can't quite come up with a reason.  E.g. a client
>typo/bug makes the optional 'a' (authzid) field be sent as 'A', so...
>it doesn't match the grammar authentication fails.  Well, good.
>Kudos to whoever wrote that grammar.
>  
>
>>>Anyway, these extensions are new to the -07 draft and I don't remember
>>>any discussion about them on this list prior to the draft, so I think it
>>>must all come from some IETF meeting discussions.  (Which is one reason
>>>I've been waiting for a more finalized draft, like I said:-)
>>>      
>>>
>>They are the result of resolving one of the open questions in -06, which is 
>>whether unrecognized attribute-value-pairs should be ignored.  The answer 
>>turned out to be "yes, except for this special one, which we reserve for 
>>future use in defining a critical extension mechanism".
>>    
>>
>That's not what the grammar does.  It only allows optional extensions
>at the end, except for the wart that "p=" comes after it in the final
>client message.
>
>Maybe it'd be cleaner to put "p=" at the _front_ of that message?
>  
>
Not really. p= is constructed from:

AuthMessage     := client-first-message + "," +
                   server-first-message + "," +
                   final-client-message-without-proof

so it covers everything, including extensions.
One can just strcat() 3 pieces together and calculate hash from them.
Arguably if p= moves to the front of the 
final-client-message-without-proof, then the has would still be easy to 
extract, but it would require extra memcopy, or some other thing.

>Then the client immediately knows where to find it, and it can happily
>ignore all fields from optional extensions to the end of the message.
>  
>
I am not sure it buys that much. Other opinions?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RL9BMJ002079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 14:09:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RL9Bea002078; Tue, 27 Jan 2009 14:09: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 n0RL8xfm002060 for <[e-mail]>; Tue, 27 Jan 2009 14:09:10 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.94.85] (92.40.94.85.sub.mbb.three.co.uk [92.40.94.85])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 27 Jan 2009 21:08:58 +0000
Message-ID: <[e-mail]>
Date: Tue, 27 Jan 2009 21:08:27 +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: Hallvard B Furuseth <[e-mail]>
CC: [e-mail]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
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>

Hallvard B Furuseth wrote:

>Now that I'm looking at SCRAM again (draft-newman-auth-scram-07.txt):
>  
>
>>4. SCRAM mechanism names
>>
>>   A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
>>   uppercased name of the underlying hashed function taken from the
>>   IANA "Hash Function Textual Names" registry.
>>    
>>
>Thus SCRAM can only use hash functions with case-insensitive names
>of max 9 of the characters [-_0-9A-Z].  See RFC 4422 section 3.1.
>  
>
Yes, I've raised this issue myself.

>Is there anything to prevent "LongCaseSensitiveName/paramName(value)"
>from being registered as a hash function?  I don't see anything in RFC
>3279 or <http://www.iana.org/assignments/hash-function-text-names/>.
>   
>Should we obsolete RFC 3279 for one which requires somewhat friendlier
>names?
>  
>
I agree with Jeff that we shouldn't obsolete this RFC. But we can try to 
put extra restrictions on the registry.

>Or do we defer any worry until it happens,
>
That too.

>and register aliases for new
>SCRAM-unfriendly names if they arrive?  We'd need to keep that option
>open anyway: I expect a 9-character limit on IANA hash function names
>could be too restrictive, in particular if someone invents and registers
>hash function family names.
>  
>

Jeffrey Hutzelman wrote:
 [...]

> In practice, I don't think we need to worry about it.  New names can 
> be added to that registry only by standards-track RFC's which update 
> or replace RFC3279, which is a pretty narrow category requiring fairly 
> wide review.  I don't expect anyone will ever try to define a hash 
> function name which is deliberately long, invalid, or ambiguous.

Agreed.

> Note, BTW, that there is no such thing as a "case-insensitive name"; 
> only case-insensitive treatment of names.  Regardless of what case 
> might be used in registering a hash function name, we can still use it 
> in a SASL mechanism name, unless/until there are two hash functions 
> whose registered names differ only in case, which I somehow doubt 
> would pass the review required for standards-track RFC's.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RKHWYc099456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 13:17:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RKHWiW099455; Tue, 27 Jan 2009 13:17:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RKHLpL099442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 27 Jan 2009 13:17:32 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (173-114-124-216.pools.spcsdns.net [173.114.124.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0RKHHB7019501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 15:17:18 -0500 (EST)
Date: Tue, 27 Jan 2009 15:17:17 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, January 27, 2009 08:47:29 PM +0100 Hallvard B Furuseth 
<[e-mail]> wrote:

> Hopefully so.  I guess it's GS2 which has me worried.  It'd never have
> occurred to me to worry that a SASL mechanism name might someday be
> named something unreadable like "GS2-DT4PIK22T6APV2PY" either.
> A similar idea but base64 instead of base32 and SASL would be in
> trouble.  Or lowercase(base64()), since I too would expect required
> case-sensitive treatment to raise loud protests.

Well, GS2 is a SASL mechanism family, and so was designed specifically with 
the requirements of SASL in mind.  Compare to RFC4462, which defines a 
family of GSS-API-based SSH key exchange algorithms using a similar 
technique, but based on the requirements of SSH.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RK15Zs098645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 13:01:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RK15hR098644; Tue, 27 Jan 2009 13:01:05 -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 n0RK12M2098638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Jan 2009 13:01:04 -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 1LRu7I-0006pz-Rd; Tue, 27 Jan 2009 21:01:00 +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 1LRu7I-0005Fu-Jt; Tue, 27 Jan 2009 21:01:00 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LRu7I-00077E-Ik; Tue, 27 Jan 2009 21:01:00 +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: Tue, 27 Jan 2009 21:01:00 +0100
To: Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 8A3B6C7AA691482BCF3A13B907F3F64CD51285A2
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1350 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>

Sorry, I lost my answer to this.

Hallvard B Furuseth writes:
> Jeffrey Hutzelman writes:
>> SCRAM is suited to small environments where it's reasonable to maintain 
>> separate authentication databases for every service, usually because there 
>> is no central infrastructure. 

I don't remember this coming up as a limitation for when to use SCRAM
before, beyond the problem with using passwords in the first place.
Does the draft say this somehow?

>> If you're trying to set up enterprise-grade 
>> distributed infrastructure, you should start with an enterprise-grade 
>> authentication service.

*I'm* not trying to set up anything in particular at the moment.  Though
I'm thinking of various things we've discussed to do in the future, or
of other services I've used myself.

I'm not sure what "enterprise-grade" is except a nice buzzword.  My
reason to choose SASL for something would likely be that it'd be the
best available and widely enough supported alternative for whatever I'm
doing.

>(...)
>>> My objection is that this point in the Introduction, standing alone, is
>>> simply false:
>>>
>>>     - The server does not gain the ability to impersonate the client to
>>>       other servers (with an exception for server-authorized proxies).
>> 
>> Hm.  Maybe.
> 
> Note that we are now talking about exceptions to the exception (the
> security considerations) to the rule (the intro statement).

The point being, the discussion around this point is bringing up a whole
host of unstated assumptions.  Some of which I've just quoted from you
above.  Maybe the point should be restated completely, after looking a
bit closer at just what it is trying to say.

-- 
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 n0RJlWUm098151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 12:47:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RJlWxB098150; Tue, 27 Jan 2009 12:47:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RJlT7n098142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Jan 2009 12:47:31 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LRtuD-0003B4-Ff; Tue, 27 Jan 2009 20:47:29 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LRtuD-0002Za-7u; Tue, 27 Jan 2009 20:47:29 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LRtuD-000768-6t; Tue, 27 Jan 2009 20:47:29 +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: Tue, 27 Jan 2009 20:47:29 +0100
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
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: AE1BF1819995E59B1C385FB5924A83F6AB93CEB5
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 2 total 1349 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>

Jeffrey Hutzelman writes:
> Well, we certainly shouldn't obsolete RFC3279, which doesn't create that 
> registry or specify its rules, but does specify names and OID's for a 
> number of hash functions in wide use today.  Besides, it's not ours.
> 
> We also shouldn't obsolete RFC4572, which does create the registry and set 
> its rules, but is mostly about specifying SDP over TLS.  Besides, it also 
> is not ours.

Argh, I took the RFC name from the wrong browser window...  Anyway, I
didn't mean "we" would do it as in SASL taking it over, more like
someone doing whatever was required.  However,

> In practice, I don't think we need to worry about it.
>
> New names can be 
> added to that registry only by standards-track RFC's which update or 
> replace RFC3279, which is a pretty narrow category requiring fairly wide 
> review.  I don't expect anyone will ever try to define a hash function name 
> which is deliberately long, invalid, or ambiguous.

Fine by me.  As long as _someone_ who knows SASL keeps track.

> Note, BTW, that there is no such thing as a "case-insensitive name"; only 
> case-insensitive treatment of names.

Right, that was sloppy.

> Regardless of what case might be used in registering a hash function
> name, we can still use it in a SASL mechanism name, unless/until there
> are two hash functions whose registered names differ only in case,
> which I somehow doubt would pass the review required for
> standards-track RFC's.

Hopefully so.  I guess it's GS2 which has me worried.  It'd never have
occurred to me to worry that a SASL mechanism name might someday be
named something unreadable like "GS2-DT4PIK22T6APV2PY" either.
A similar idea but base64 instead of base32 and SASL would be in
trouble.  Or lowercase(base64()), since I too would expect required
case-sensitive treatment to raise loud protests.

-- 
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 n0RJUeCW097490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 12:30:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RJUeEh097489; Tue, 27 Jan 2009 12:30:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RJUbj0097482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Jan 2009 12:30:39 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LRtds-0001Wn-Ha; Tue, 27 Jan 2009 20:30:36 +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 1LRtds-00062U-73; Tue, 27 Jan 2009 20:30:36 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LRtds-00074o-5q; Tue, 27 Jan 2009 20:30:36 +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: Tue, 27 Jan 2009 20:30:36 +0100
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: E85A00227D3B35CBD5B634D3490AD6F0F0540536
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1348 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>

Jeffrey Hutzelman writes:
>--On Tuesday, January 27, 2009 07:00:55 PM +0100 Hallvard B Furuseth 
><[e-mail]> wrote:
>>     "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."
>>
>> Just add something amounting to "...except when it correctly matches an
>> extension the implementation implements", and maybe some words from your
>> description.  Then extension documents will no longer need to contradict
>> the original description which says it MUST fail.
> 
> No no.  The idea is that it MUST fail unless you are implementing a newer 
> version of the spec which defines different behavior.

But isn't that what I just said?  Except if we are talking of *a* newer
version of the spec, I think calling it "extensions" is a misnomer.
Should be something about "reserved" instead.  

> This is not (yet) an extensibility mechanism; it's a field reserved
> for use by a later version of the spec.

That sounds unproblematic if you are talking about a newer version of
the spec which "obsoletes" this one rather than one of several
extensions which "updates" it.  But now you need to specify that this
is how the field is expected to be updated.  Not necessarily in that
seciont, could go in an appendix.

>> Hold on.  I think that's a bug anyway.  The draft should say that auth
>> MUST be aborted if a message doesn't match the grammar in Section 6.
> 
> No, we've been over this, and the consensus was that extension fields 
> should be non-critical; that is, unrecognized extensions are ignored.

Not _mandatory_ extensions, since an older SASL implementation will
abort the authentication when it sees "m=".

> This is reflected by the grammar in section 6, which allows arbitrary
> unrecognized name=value pairs in several places.

Only the optional extensions ("extensions" grammar symbol), which is at
a fixed place in each message.

>> That will automatically support the 'm=' definition as it is described
>> now, since an initial unknown field does not match the grammar..
>> So the draft could support mandatory extensions just by saying extension
>> documents should place them at the beginning.  And optional ones can
>> stay at the end, where they are ignored when unrecognized.
> 
> Hrm.  That's an interesting approach, and it might even work.  But I'm not 
> really thrilled with the idea of making the order matter more than it 
> already does.  The grammar currently describes fields in a particular 
> order, but I would expect implementations to accept them in any order in 
> practice, and depending on implementations _not_ to do so seems brittle. 
> I'm much happier with an field whose criticality is indicated by its name 
> rather than by its position.

I'm quite happy with a required order.  Easier to parse, and no need to
catch and hopefully fail on multiple occurrences of the same field name.

Admittedly order-dependent meaning of extension fields does make me
nervous, but I can't quite come up with a reason.  E.g. a client
typo/bug makes the optional 'a' (authzid) field be sent as 'A', so...
it doesn't match the grammar authentication fails.  Well, good.
Kudos to whoever wrote that grammar.

>> Anyway, these extensions are new to the -07 draft and I don't remember
>> any discussion about them on this list prior to the draft, so I think it
>> must all come from some IETF meeting discussions.  (Which is one reason
>> I've been waiting for a more finalized draft, like I said:-)
> 
> They are the result of resolving one of the open questions in -06, which is 
> whether unrecognized attribute-value-pairs should be ignored.  The answer 
> turned out to be "yes, except for this special one, which we reserve for 
> future use in defining a critical extension mechanism".

That's not what the grammar does.  It only allows optional extensions
at the end, except for the wart that "p=" comes after it in the final
client message.

Maybe it'd be cleaner to put "p=" at the _front_ of that message?
Then the client immediately knows where to find it, and it can happily
ignore all fields from optional extensions to the end of the message.

>> Define "correctly".  (...)
> 
> if you have a bunch of mirror servers providing the same service,

Mirrors need not provide the same service, in several ways:

> there's really no reason _not_ to use the same salt on all of them.
> There's no reason for one LDAP server to impersonate a user to another
> in the same pool.

Sure there is.  A central well-protected server mirroring to servers
physically present elsewhere, maybe in less protected places (so a
break-in is easier), and/or run by different admins with different
privileges and trust.  Or the servers only mirror a subset of the
directory, or allow access to different people/networks, so they do not
in fact provide the same service.

> SCRAM is suited to small environments where it's reasonable to maintain 
> separate authentication databases for every service, usually because there 
> is no central infrastructure.  If you're trying to set up enterprise-grade 
> distributed infrastructure, you should start with an enterprise-grade 
> authentication service.
> 
>> I agree that by itself, the point belongs in Security Considerations.
>> My objection is that this point in the Introduction, standing alone, is
>> simply false:
>>
>>     - The server does not gain the ability to impersonate the client to
>>       other servers (with an exception for server-authorized proxies).
> 
> Hm.  Maybe.

Note that we are now talking about exceptions to the exception (the
security considerations) to the rule (the intro statement).

Also you are talking from the administrator point of view.  The
statement looks quite different from a user (or client author) point of
view, if he sends/stores his password through the protocol.
Also to someone browsing various specs to see what claims they make, in
order to _later_ look more carefully at the promising ones.

-- 
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 n0RJB3io096403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 12:11:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RJB3ZZ096402; Tue, 27 Jan 2009 12:11:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RJB2et096391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 27 Jan 2009 12:11:03 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0RJAwjK015515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 14:10:59 -0500 (EST)
Date: Tue, 27 Jan 2009 14:10:58 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: IANA Hash Function Textual Names vs. SCRAM mechanism names
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, January 27, 2009 07:31:25 PM +0100 Hallvard B Furuseth 
<[e-mail]> wrote:

>
> Is there anything to prevent "LongCaseSensitiveName/paramName(value)"
> from being registered as a hash function?  I don't see anything in RFC
> 3279 or <http://www.iana.org/assignments/hash-function-text-names/>.
>
> Should we obsolete RFC 3279 for one which requires somewhat friendlier
> names?

Well, we certainly shouldn't obsolete RFC3279, which doesn't create that 
registry or specify its rules, but does specify names and OID's for a 
number of hash functions in wide use today.  Besides, it's not ours.

We also shouldn't obsolete RFC4572, which does create the registry and set 
its rules, but is mostly about specifying SDP over TLS.  Besides, it also 
is not ours.

In practice, I don't think we need to worry about it.  New names can be 
added to that registry only by standards-track RFC's which update or 
replace RFC3279, which is a pretty narrow category requiring fairly wide 
review.  I don't expect anyone will ever try to define a hash function name 
which is deliberately long, invalid, or ambiguous.

Note, BTW, that there is no such thing as a "case-insensitive name"; only 
case-insensitive treatment of names.  Regardless of what case might be used 
in registering a hash function name, we can still use it in a SASL 
mechanism name, unless/until there are two hash functions whose registered 
names differ only in case, which I somehow doubt would pass the review 
required for standards-track RFC's.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RIVnGk093366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 11:31:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RIVnBM093365; Tue, 27 Jan 2009 11:31:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RIVmYn093358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 27 Jan 2009 11:31:49 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0RIVhKp013777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 13:31:45 -0500 (EST)
Date: Tue, 27 Jan 2009 13:31:43 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, [e-mail], [e-mail]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, January 27, 2009 07:00:55 PM +0100 Hallvard B Furuseth 
<[e-mail]> wrote:

> [I should have changed the subject.  Better late than nenver...]
>
> Jeffrey Hutzelman writes:
>> --On Tuesday, January 27, 2009 03:37:41 PM +0100 Hallvard B Furuseth
>> <[e-mail]> wrote:
>>
>>> - The "m" (Mandatory extensions) field still seems poorly defined to me.
>>>
>>>   For one thing the wording is unfortunate - an extension will have to
>>>   break the spec which says "m" must cause failure.
>>
>> It's deliberately not very specified.
>
> Yes, but so far we are talking about how the intended (vague) spec is
> _worded_.  Which led me to completely misunderstand what was meant, see
> the discussion in December.
>
>     "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."
>
> Just add something amounting to "...except when it correctly matches an
> extension the implementation implements", and maybe some words from your
> description.  Then extension documents will no longer need to contradict
> the original description which says it MUST fail.

No no.  The idea is that it MUST fail unless you are implementing a newer 
version of the spec which defines different behavior.  This is not (yet) an 
extensibility mechanism; it's a field reserved for use by a later version 
of the spec.

> Hold on.  I think that's a bug anyway.  The draft should say that auth
> MUST be aborted if a message doesn't match the grammar in Section 6.

No, we've been over this, and the consensus was that extension fields 
should be non-critical; that is, unrecognized extensions are ignored.  This 
is reflected by the grammar in section 6, which allows arbitrary 
unrecognized name=value pairs in several places.

> That will automatically support the 'm=' definition as it is described
> now, since an initial unknown field does not match the grammar..
> So the draft could support mandatory extensions just by saying extension
> documents should place them at the beginning.  And optional ones can
> stay at the end, where they are ignored when unrecognized.

Hrm.  That's an interesting approach, and it might even work.  But I'm not 
really thrilled with the idea of making the order matter more than it 
already does.  The grammar currently describes fields in a particular 
order, but I would expect implementations to accept them in any order in 
practice, and depending on implementations _not_ to do so seems brittle. 
I'm much happier with an field whose criticality is indicated by its name 
rather than by its position.

> Anyway, these extensions are new to the -07 draft and I don't remember
> any discussion about them on this list prior to the draft, so I think it
> must all come from some IETF meeting discussions.  (Which is one reason
> I've been waiting for a more finalized draft, like I said:-)

They are the result of resolving one of the open questions in -06, which is 
whether unrecognized attribute-value-pairs should be ignored.  The answer 
turned out to be "yes, except for this special one, which we reserve for 
future use in defining a critical extension mechanism".


> Define "correctly".  Generate some unneeded SCRAM hashes for each
> password and store them somewhere safe, in anticipation of the day
> when we'll decide to add some extra servers?  Or ask all users to
> change passwords because we've added another LDAP server or whatever?

if you have a bunch of mirror servers providing the same service, there's 
really no reason _not_ to use the same salt on all of them.  There's no 
reason for one LDAP server to impersonate a user to another in the same 
pool.  Put another way, you may have multiple machines, but they are 
providing the same _service_.

SCRAM is suited to small environments where it's reasonable to maintain 
separate authentication databases for every service, usually because there 
is no central infrastructure.  If you're trying to set up enterprise-grade 
distributed infrastructure, you should start with an enterprise-grade 
authentication service.

> I agree that by itself, the point belongs in Security Considerations.
> My objection is that this point in the Introduction, standing alone, is
> simply false:
>
>     - The server does not gain the ability to impersonate the client to
>       other servers (with an exception for server-authorized proxies).

Hm.  Maybe.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RIVcjt093348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 11:31:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RIVcgO093347; Tue, 27 Jan 2009 11:31:38 -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 n0RIVQVU093332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Jan 2009 11:31:38 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LRsic-00071V-4O for [e-mail]; Tue, 27 Jan 2009 19:31:26 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LRsib-0008RZ-T6; Tue, 27 Jan 2009 19:31:26 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LRsib-0006y0-Rb; Tue, 27 Jan 2009 19:31:25 +0100
Message-Id: <[e-mail]>
From: Hallvard B Furuseth <[e-mail]>
To: [e-mail]
Subject: IANA Hash Function Textual Names vs. SCRAM mechanism names
Date: Tue, 27 Jan 2009 19:31:25 +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: BD650737588B0A9C65DC9224CB4043C9AFABCC47
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 1 bait 0 mail/h: 2 total 1347 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>

Now that I'm looking at SCRAM again (draft-newman-auth-scram-07.txt):

> 4. SCRAM mechanism names
>
>    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
>    uppercased name of the underlying hashed function taken from the
>    IANA "Hash Function Textual Names" registry.

Thus SCRAM can only use hash functions with case-insensitive names
of max 9 of the characters [-_0-9A-Z].  See RFC 4422 section 3.1.

Is there anything to prevent "LongCaseSensitiveName/paramName(value)"
from being registered as a hash function?  I don't see anything in RFC
3279 or <http://www.iana.org/assignments/hash-function-text-names/>.
   
Should we obsolete RFC 3279 for one which requires somewhat friendlier
names?

Or do we defer any worry until it happens, and register aliases for new
SCRAM-unfriendly names if they arrive?  We'd need to keep that option
open anyway: I expect a 9-character limit on IANA hash function names
could be too restrictive, in particular if someone invents and registers
hash function family names.

-- 
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 n0RI1Bhr091151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 11:01:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RI1B47091150; Tue, 27 Jan 2009 11:01:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RI0whn091115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Jan 2009 11:01:10 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LRsF5-0001Dp-S3; Tue, 27 Jan 2009 19:00:55 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LRsF5-0000be-IL; Tue, 27 Jan 2009 19:00:55 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LRsF5-0006tJ-GG; Tue, 27 Jan 2009 19:00:55 +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: Tue, 27 Jan 2009 19:00:55 +0100
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: SCRAM notes (was: ABNF for the three cases of SCRAM as GS2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 0B80291BDF18267F656765DAB524450AB0F4A0EF
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 1 bait 0 mail/h: 1 total 1346 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 should have changed the subject.  Better late than nenver...]

Jeffrey Hutzelman writes:
>--On Tuesday, January 27, 2009 03:37:41 PM +0100 Hallvard B Furuseth 
><[e-mail]> wrote:
> 
>> - The "m" (Mandatory extensions) field still seems poorly defined to me.
>>
>>   For one thing the wording is unfortunate - an extension will have to
>>   break the spec which says "m" must cause failure.
> 
> It's deliberately not very specified.

Yes, but so far we are talking about how the intended (vague) spec is
_worded_.  Which led me to completely misunderstand what was meant, see
the discussion in December.

    "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."

Just add something amounting to "...except when it correctly matches an
extension the implementation implements", and maybe some words from your
description.  Then extension documents will no longer need to contradict
the original description which says it MUST fail.

As for it's (intended) definition:

>>   Why not define that syntax in SCRAM?
> 
> I'd be happy to see that happen, but some participants felt that that was 
> more complexity than was needed.  We could have just left it out entirely, 
> but then it would be impossible to ever add a critical field, because 
> implementations of the earlier spec wouldn't be required to fail.

Hold on.  I think that's a bug anyway.  The draft should say that auth
MUST be aborted if a message doesn't match the grammar in Section 6.

That will automatically support the 'm=' definition as it is described
now, since an initial unknown field does not match the grammar..
So the draft could support mandatory extensions just by saying extension
documents should place them at the beginning.  And optional ones can
stay at the end, where they are ignored when unrecognized.

Anyway, these extensions are new to the -07 draft and I don't remember
any discussion about them on this list prior to the draft, so I think it
must all come from some IETF meeting discussions.  (Which is one reason
I've been waiting for a more finalized draft, like I said:-)

>>> 1.2. Notation
>>>    U0   := HMAC(str, salt || INT(1))
>>
>> Make that HMAC(str, (salt || INT(1))) or HMAC((str, salt) || INT(1)).
> 
> Uh, why?  It's pretty clear than an HMAC requires two arguments (key and 
> message); in fact, that's about three paragraphs above the text you quote. 

Nothing important.  Just a bit easier to read.  Or rather, to glance at
without needing to read as far as three paragraphs away.

> I'm not sure what you think "(str,salt) || INT(1)" would even mean.

The meaning would be "I'm sure I'll find out when I've read a bit more".
Which is a fairly common thought for me when browsing specifications:-)

>>> 2. Introduction
>>> - The server does not gain the ability to impersonate the client to
>>>   other servers (with an exception for server-authorized proxies).
>>
>> Another exception: An authentication exchange provides enough info to
>> authenticate as the same user on another server
> 
> ... only if the two servers used the same salt, which we specifically
> warn against.

Yes, I said that.  But actually I don't see a warning against it.

  "For this reason, it is important to use randomly-generated salt values."

doesn't say "different ... for different servers".

Also that paragraph only mentions attackers, not untrusted servers.

> Implemented _correctly_ the protocol does not have this
> weakness.  I think the current approach of warning against doing this
> wrong in security considerations is sufficient.

It's a security concern to be aware of.  What to do about it is up
to the admin.

Define "correctly".  Generate some unneeded SCRAM hashes for each
password and store them somewhere safe, in anticipation of the day
when we'll decide to add some extra servers?  Or ask all users to
change passwords because we've added another LDAP server or whatever?

Also such correct behavior would need to override mirroring
functionality between servers.

I agree that by itself, the point belongs in Security Considerations.
My objection is that this point in the Introduction, standing alone, is
simply false:

    - The server does not gain the ability to impersonate the client to
      other servers (with an exception for server-authorized proxies).

This explicitly appears to refer to an untrusted server.  One shouldn't
need to go to the The Security Considerations to see that "well, that's
sort of true, as long as the server does <this>".  The intro section
gives the wrong message to a user, and the wrong message to an admin
since having different salts on different server may amount to a major
job.

-- 
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 n0RHGvAA088966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 10:16:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RHGvPo088965; Tue, 27 Jan 2009 10:16:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RHGjJe088944 for <[e-mail]>; Tue, 27 Jan 2009 10:16:56 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.178] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 27 Jan 2009 17:16:44 +0000
Message-ID: <[e-mail]>
Date: Tue, 27 Jan 2009 17:16:08 +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: Jeffrey Hutzelman <[e-mail]>, Hallvard B Furuseth <[e-mail]>
CC: [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman wrote:

> --On Tuesday, January 27, 2009 03:37:41 PM +0100 Hallvard B Furuseth 
> <[e-mail]> wrote:
>
>> - The "m" (Mandatory extensions) field still seems poorly defined to me.
>>
>>   For one thing the wording is unfortunate - an extension will have to
>>   break the spec which says "m" must cause failure.
>
> It's deliberately not very specified.  The idea is that the first time 
> we need this functionality, it will be necessary for a standards-track 
> document to amend the specification to describe the syntax of this 
> field and the circumstances under which its presence does not cause 
> failure.

I think this explains "m=" handling very well.

>>   Why not define that syntax in SCRAM?
>
> I'd be happy to see that happen, but some participants felt that that 
> was more complexity than was needed.  We could have just left it out 
> entirely, but then it would be impossible to ever add a critical 
> field, because implementations of the earlier spec wouldn't be 
> required to fail.  So, we were able to convince those people to 
> compromise by making the minimum possible provision for future 
> critical fields, which is to define a specific field whose contents 
> are currently unspecified and whose presence currently triggers failure.

+1.

>>> 1.2. Notation
>>>    U0   := HMAC(str, salt || INT(1))
>>
>> Make that HMAC(str, (salt || INT(1))) or HMAC((str, salt) || INT(1)).
>
> Uh, why?  It's pretty clear than an HMAC requires two arguments (key 
> and message); in fact, that's about three paragraphs above the text 
> you quote. I'm not sure what you think "(str,salt) || INT(1)" would 
> even mean.

Agreed.

>>> 2. Introduction
>>> - The server does not gain the ability to impersonate the client to
>>>   other servers (with an exception for server-authorized proxies).
>>
>> Another exception: An authentication exchange provides enough info to
>> authenticate as the same user on another server
>
> ... only if the two servers used the same salt, which we specifically 
> warn against.  Implemented _correctly_ the protocol does not have this 
> weakness. I think the current approach of warning against doing this 
> wrong in security considerations is sufficient.

I agree, but I will check to make sure that the document is consistent 
with this advice.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RGnwA8087747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 09:49:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RGnw9v087746; Tue, 27 Jan 2009 09:49:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RGnkYt087739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 27 Jan 2009 09:49:57 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0RGngtP009405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 11:49:43 -0500 (EST)
Date: Tue, 27 Jan 2009 11:49:42 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Hallvard B Furuseth <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, January 27, 2009 03:37:41 PM +0100 Hallvard B Furuseth 
<[e-mail]> wrote:

> - The "m" (Mandatory extensions) field still seems poorly defined to me.
>
>   For one thing the wording is unfortunate - an extension will have to
>   break the spec which says "m" must cause failure.

It's deliberately not very specified.  The idea is that the first time we 
need this functionality, it will be necessary for a standards-track 
document to amend the specification to describe the syntax of this field 
and the circumstances under which its presence does not cause failure.

>   Why not define that syntax in SCRAM?

I'd be happy to see that happen, but some participants felt that that was 
more complexity than was needed.  We could have just left it out entirely, 
but then it would be impossible to ever add a critical field, because 
implementations of the earlier spec wouldn't be required to fail.  So, we 
were able to convince those people to compromise by making the minimum 
possible provision for future critical fields, which is to define a 
specific field whose contents are currently unspecified and whose presence 
currently triggers failure.


>> 1.2. Notation
>>    U0   := HMAC(str, salt || INT(1))
>
> Make that HMAC(str, (salt || INT(1))) or HMAC((str, salt) || INT(1)).

Uh, why?  It's pretty clear than an HMAC requires two arguments (key and 
message); in fact, that's about three paragraphs above the text you quote. 
I'm not sure what you think "(str,salt) || INT(1)" would even mean.


>> 2. Introduction
>> - The server does not gain the ability to impersonate the client to
>>   other servers (with an exception for server-authorized proxies).
>
> Another exception: An authentication exchange provides enough info to
> authenticate as the same user on another server

... only if the two servers used the same salt, which we specifically warn 
against.  Implemented _correctly_ the protocol does not have this weakness. 
I think the current approach of warning against doing this wrong in 
security considerations is sufficient.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0REbupM079130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 07:37:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0REbugH079129; Tue, 27 Jan 2009 07:37:56 -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 n0REbh86079109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Jan 2009 07:37:55 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1LRp4Q-0000j2-7P; Tue, 27 Jan 2009 15:37:42 +0100
Received: from bombur.uio.no ([129.240.6.233]) by mail-mx3.uio.no with esmtp  (Exim 4.69) (envelope-from <[e-mail]>) id 1LRp4Q-00037B-04; Tue, 27 Jan 2009 15:37:42 +0100
Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1LRp4P-0006UN-Kh; Tue, 27 Jan 2009 15:37:41 +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: Tue, 27 Jan 2009 15:37:41 +0100
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.18 under Emacs 22.2.1
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 409BCAF2F6AA5983BDB9A70AFE42693B0C171138
X-UiO-SPAM-Test: remote_host: 129.240.6.233 spam_score: -49 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 1344 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>

Alexey Melnikov writes:
> To clarify: I will produce both the updated (hopefully final) version
> of SCRAM without GS2-related changes, plus another version which
> contains GS2 related ABNF and examples.

Likely not final.  Then your first versions of the "To be written"
appendixes woudl have to pass through with almost no discussion.

I've been waiting for a more finalized draft (by now, in particular
Appendix B) before doing a careful review, and reposting some concerns
of mine in case the authors just hadn't gotten to them yet.  Appendix B
to possibly short-circuit discussion of some other details.  But I can
look through the archives and my notes and (re-)post, if you want.

Some old and new points I remember off-hand:

- Regarding GS2, let me just make a general protest againt the verbose
  way the derivation of GS2 names are spelled out in... I don't remember
  which mechanism draft(s) at the moment.  Just say it has

   "GSS-API mechanism OID: <whatever>
    SASL mechanism name: GS2-<whatever> due to [GS2] section 3)"

- The "m" (Mandatory extensions) field still seems poorly defined to me.

  For one thing the wording is unfortunate - an extension will have to
  break the spec which says "m" must cause failure.

  Next, it'll need further syntax to disambiguate between extensions.
  Why not define that syntax in SCRAM?  E.g. lowercase letters for
  mandatory-to-implement fields and uppercase for optional fields
  ("extensions" in the syntax).

  Or two-letter extension fields: "m" starting a mandatory extension
  and "o" starting an optional one.

> 1.1. Terminology
>    Some clarifications and additional definitions follow:

What's a server-authorized proxy?

> 1.2. Notation
>    U0   := HMAC(str, salt || INT(1))

Make that HMAC(str, (salt || INT(1))) or HMAC((str, salt) || INT(1)).

> 2. Introduction
> - The server does not gain the ability to impersonate the client to
>   other servers (with an exception for server-authorized proxies).

Another exception: An authentication exchange provides enough info to
authenticate as the same user on another server which stores the same
authentication info for that user.  Mentioned as a security
consideration, but I think it belongs with this statement: it's
trivially inherent in the algorithm, and servers with the same data
(mirrors/slaves) is a common scenario.

> 5. SCRAM Authentication Exchange
>    Servers SHOULD announce a hash iteration-count of at least 128.

Why?  Different hash algorithms have different strengths and different
costs to compute, thus I'd think this depends on the hash algorithm.
And, for that matter, on the strength of expected attacks.

Also, how does an iteration count of more than 1 help on a site where
passwords are stored in several forms anyway, maybe including salted MD5
for Unix crypt()?  (Maybe that's for Appendix B or C, I don't know.)

If I remember correctly (and I may not), one problem with the proposed
competing SRP mechanism was the computation cost.  How does that compare
with a high SCRAM iteration count?

-- 
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 n0QLV5H6036824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 14:31:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QLV53d036823; Mon, 26 Jan 2009 14:31:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QLV4QU036817 for <[e-mail]>; Mon, 26 Jan 2009 14:31:04 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.187.17] (92.40.187.17.sub.mbb.three.co.uk [92.40.187.17])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 26 Jan 2009 21:31:02 +0000
Message-ID: <[e-mail]>
Date: Mon, 26 Jan 2009 21:30:27 +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: ABNF for the three cases of SCRAM as GS2
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[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:

> I think I have enough information to produce a version of SCRAM that 
> would look like Sam's proposal 2 or 3.

To clarify: I will produce both the updated (hopefully final) version of 
SCRAM without GS2-related changes, plus another version which contains 
GS2 related ABNF and examples. Then people can compare the two and make 
a choice. Once the choice is done, I will post the version that should 
be ready for WGLC.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QHAqMR023924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 10:10:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QHAqLt023923; Mon, 26 Jan 2009 10:10:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QHAeur023883 for <[e-mail]>; Mon, 26 Jan 2009 10:10:51 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.6] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 26 Jan 2009 17:10:39 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Mon, 26 Jan 2009 17:10:04 +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: ABNF for the three cases of SCRAM as GS2
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sam Hartman wrote:

>mic-of-something basically results to hmac(something) for some hmac
>key that the SCRAm GS2 mechanism needs to define.  I'd be much happier
>if it was derived from the scram key, not identical to it.  So,
>hmac(hmac(scram_key,micderivation_constant),stuff)
>  
>
Sam clarified to me that "stuff" is gs2-to-be-protected, defined by Sam as:
   gs2-to-be-protected = qop ["," maxbuf] ["," cbqop "," channelbinding] 
["," authzid] ["," 1*extension]

I think I have enough information to produce a version of SCRAM that 
would look like Sam's proposal 2 or 3.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QFJYol018401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 08:19:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0QFJYcw018400; Mon, 26 Jan 2009 08:19:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QFJKOp018391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 26 Jan 2009 08:19:33 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D7037451D; Mon, 26 Jan 2009 10:19:10 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F> <[e-mail]>
Date: Mon, 26 Jan 2009 10:19:10 -0500
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Sat, 24 Jan 2009 22:35:14 +0000")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

mic-of-something basically results to hmac(something) for some hmac
key that the SCRAm GS2 mechanism needs to define.  I'd be much happier
if it was derived from the scram key, not identical to it.  So,
hmac(hmac(scram_key,micderivation_constant),stuff)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0OMZp8D023604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2009 15:35:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0OMZpZg023603; Sat, 24 Jan 2009 15:35:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0OMZd50023594 for <[e-mail]>; Sat, 24 Jan 2009 15:35:50 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.44.167] (92.40.44.167.sub.mbb.three.co.uk [92.40.44.167])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 24 Jan 2009 22:35:36 +0000
Message-ID: <[e-mail]>
Date: Sat, 24 Jan 2009 22:35:14 +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: Chris Newman <[e-mail]>
CC: Sam Hartman <[e-mail]>, [e-mail]
Subject: Re: ABNF for the three cases of SCRAM as GS2
References: <[e-mail]> <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F>
In-Reply-To: <AC527E6743C0778FBAE824B4@446E7922C82D299DB29D899F>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris Newman wrote:

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

I just reviewed what two of you were talking about, so I think I am on 
the same page now.
My reply is a bit long, as I try to explain how I came to various 
conclusions. I hope other readers of this message will find my 
explanation useful.

> 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.

I've done the same thing.

>   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).

Right, I saw you dropping repeated nonce in the second client response.

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

A think you got it more or less correct.

A general comment on what Sam done (which helped me to understand his 
proposals): I think he basically looked at draft-ietf-sasl-gs2 and made 
alternative encodings of the data presented there. He then took ABNF 
draft-newman-auth-scram and tried to modify it, so that GS2 and the 
modified-SCRAM ABNFs agree.

> 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 dislike this choice in the same way you do, so let's ignore it.
However I will give answers/comments on your questions below, as they 
apply to all 3 cases.

> I'm don't understand how a SASL-SCRAM implementation is supposed to 
> generate the <MIC-of-something> that GSS wrap does.

I am not sure either.

> 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 think so, but I hope that calculating a MIC in order to protect 
from replays is fairly easy.

> I don't understand why two sets of channel bindings appear to be present,

One channel binding is as used in SASL. The other is 
GSS-CHANNEL-BINDINGS from 
draft-ietf-kitten-gssapi-channel-bindings-05.txt, i.e. a parameter 
passed to GSS_Init_sec_context() and GSS_Accept_sec_context() calls.

> 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.

If you look at draft-ietf-sasl-gs2-10.txt, section 5, you will find that 
the GSS-API channel binding parameter must be NULL for GS2. So it would 
always be encoded as an empty string, or would be missing entirely (I am 
not sure exactly how this would look in GSS framing).

> 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.

My current understanding of this is that:
If you look at section 4.3 of draft-ietf-sasl-gs2-10.txt, you will find 
there the following (section 4.3.2):

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  client_qops  |               client_maxbuf                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   channel_binding_length                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |[client_cbqops]|          [channel_binding_data]               /
      /                                                               /
      /                         /      [authzid]                      /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

which Sam represented in the textual form as:

gs2-to-be-protected = qop ["," maxbuf] ["," cbqop "," channelbinding]
    ["," authzid] ["," 1*extension]

I.e. the authorization identity is going to be transported by the GS2 
layer itself.

> 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

After substitution I got:

C1: oidgunk username "," c-nonce delim
S1: s-nonce "," salt "," iteration-count delim
C2: s-nonce "," gss-channel-binding "," proof delim "mic=" base64() ["," 
1*extension] ",d=" c-qop ["," c-maxbuf ] ["," c-cbqop "," 
channelbinding] ["," authzid] ["," 1*extension]
S2: verifier delim "mic=" base64() ["," 1*extension] ",d=" s-qop ["," 
s-maxbuf] ["," 1*extension]

Here channelbinding is the channel binding as used by SASL.
I am not sure why Sam has put gss-channel-binding in the middle of SCRAM 
C2 step though. However it would expand to nothing, as per my earlier 
comment.

If SCRAM never negotiates a security layer, then c-qop, c-maxbuf, 
c-cbqop, s-qop and s-maxbuf become constants.

> Escaping is used where necessary to avoid delim.  Other than not 
> wanting a NUL delim due to the negative impact it has on debugging

Agreed.

> (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 got:

C1: "ctx"= oidgunk username "," c-nonce
S1: "ctx"= s-nonce "," salt "," iteration-count
C2: "mic=" base64() "," c-qop ["," c-maxbuf ] ["," c-cbqop "," 
channelbinding] ["," authzid] ["," 1*extension] ",ctx=" s-nonce "," 
gss-channel-binding "," proof
S2: "mic=" base64()  "," s-qop ["," s-maxbuf] ["," 1*extension] ",ctx=" 
verifier

=========
Currently SCRAM is defined as follows:

C1: [mandatory-exts ","] [authzid ","] username "," c-nonce ["," extensions]
S1: [mandatory-exts ","] s-nonce "," salt "," iteration-count ["," 
extensions]
C2: s-nonce "," channel-binding ["," extensions] "," proof
S2: verifier ["," extensions]

> 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.

Agreed. Cases 2 and 3 seem to mostly differ in ordering.

> Regardless, it seems fine to me.

[Sam's message deleted]



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0NC2KGS030674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 05:02:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0NC2Kgh030673; Fri, 23 Jan 2009 05:02:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0NC27MW030654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 23 Jan 2009 05:02:19 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LQKjd-0001GY-RS; Fri, 23 Jan 2009 13:02:06 +0100
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: gs2 hashed oids
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090123:[e-mail]::2xu4HARUOLwBGmN3:0FsH
X-Hashcash: 1:22:090123:[e-mail]::V6uuYjZfxvEb24qV:2UxI
Date: Fri, 23 Jan 2009 13:02:04 +0100
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Thu, 22 Jan 2009 22:46:36 -0800")
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.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> I have review this thread and the history.
>
> The WG previously made a design choice to use "hashed" GS2- mechanism
> names instead of individually "registered" SASL names.  This design
> choice was reviewed as part of the previous WG Last Call(s) and
> believed to be supported by WG consensus.
>
> In reviewing the recent discussions, I find that while there is a camp
> who prefers "registered" SASL names, most in this came can live with
> "hashed" names.  However, those in the "hashed" camp cannot live with
> "registered" SASL names because with "registered" SASL names GSS-API
> mechanisms could not automatically be SASL mechanisms within an
> implementation.  It seems the latter camp has a stronger technical
> argument.
>
> Hence, I find that there is insufficient consensus to change to
> "registered" SASL names.

Thanks for making this call.  Once the SCRAM wire syntax question is
decided, I can resume work on GS2 and will then keep the current hash
approach to mech names.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0N6krph015482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 23:46:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0N6krsG015480; Thu, 22 Jan 2009 23:46: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 n0N6kfh4015470 for <[e-mail]>; Thu, 22 Jan 2009 23:46:53 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] ((unknown) [75.141.233.128])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <[e-mail]> for <[e-mail]>; Fri, 23 Jan 2009 06:46:39 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Subject: Re: gs2 hashed oids
Date: Thu, 22 Jan 2009 22:46:36 -0800
References: <[e-mail]>
X-Mailer: Apple Mail (2.930.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have review this thread and the history.

The WG previously made a design choice to use "hashed" GS2- mechanism  
names instead of individually "registered" SASL names.  This design  
choice was reviewed as part of the previous WG Last Call(s) and  
believed to be supported by WG consensus.

In reviewing the recent discussions, I find that while there is a camp  
who prefers "registered" SASL names, most in this came can live with  
"hashed" names.  However, those in the "hashed" camp cannot live with  
"registered" SASL names because with "registered" SASL names GSS-API  
mechanisms could not automatically be SASL mechanisms within an  
implementation.  It seems the latter camp has a stronger technical  
argument.

Hence, I find that there is insufficient consensus to change to  
"registered" SASL names.

-- Kurt, as SASL co-chair



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KAqoj3005643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 03:52:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KAqorH005642; Tue, 20 Jan 2009 03:52:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KAqnMQ005635 for <[e-mail]>; Tue, 20 Jan 2009 03:52:49 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.181.102] (92.40.181.102.sub.mbb.three.co.uk [92.40.181.102])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SXWs=[e-mail]>; Tue, 20 Jan 2009 10:52:48 +0000
Message-ID: <[e-mail]>
Date: Tue, 20 Jan 2009 10:52:35 +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: [IETF Meeting Session Request Tool] sasl - New Meeting Session Request for IETF 74
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu wrote:

>Please let me know if I should revise the conflict list.
>  
>
 [...]

>Conflicts to Avoid:
>  First Priority: apparea saag sieve krb-wg kitten vcarddav
>  
>
Hi Tom,
Can you please add "morg" and "xmpp BOF" to the first priority list?

>  Second Priority: dkim emu eai pkix
>  Third Priority: httpbis idnabis lemonade smime tls
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KAqWYu005623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jan 2009 03:52:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0KAqWtj005622; Tue, 20 Jan 2009 03:52:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0KAqK35005599 for <[e-mail]>; Tue, 20 Jan 2009 03:52:32 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.181.102] (92.40.181.102.sub.mbb.three.co.uk [92.40.181.102])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 20 Jan 2009 10:52:18 +0000
Message-ID: <[e-mail]>
Date: Tue, 20 Jan 2009 10:52:05 +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: [IETF Meeting Session Request Tool] sasl - New Meeting Session Request for IETF 74
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Yu wrote:

>Please let me know if I should revise the conflict list.
>  
>
 [...]

>Conflicts to Avoid:
>  First Priority: apparea saag sieve krb-wg kitten vcarddav
>  
>
Hi Tom,
Can you please add "morg" to the first priority list?

>  Second Priority: dkim emu eai pkix
>  Third Priority: httpbis idnabis lemonade smime tls
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0K1Hv0f076034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 18:17:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0K1Hv9e076033; Mon, 19 Jan 2009 18:17:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from fugue.toroid.org (fugue.toroid.org [85.10.196.113]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0K1HkU0076020 for <[e-mail]>; Mon, 19 Jan 2009 18:17:56 -0700 (MST) (envelope-from [e-mail])
Received: from penne.toroid.org (penne-vpn [10.8.0.6]) by fugue.toroid.org (Postfix) with ESMTP id 31D25558413; Tue, 20 Jan 2009 02:17:44 +0100 (CET)
Received: by penne.toroid.org (Postfix, from userid 1000) id 1F2C638812A; Tue, 20 Jan 2009 06:47:42 +0530 (IST)
Date: Tue, 20 Jan 2009 06:47:42 +0530
From: Abhijit Menon-Sen <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
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]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2009-01-18 21:48:07 +0000, [e-mail] wrote:
>
> So, any objections of changing "value-safe-char" to be any UTF-8
> encoded Unicode character except for NUL (which is universally
> disallowed), "=" and ","?

Fine with me.

-- ams



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0K0tEao074674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 17:55:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0K0tE6f074673; Mon, 19 Jan 2009 17:55: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 n0K0t23G074656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 19 Jan 2009 17:55: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 n0K0ssWI000310 for <[e-mail]>; Mon, 19 Jan 2009 19:54:55 -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 n0K0sqNu009483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 19 Jan 2009 19:54:54 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n0K0sqig004156; Mon, 19 Jan 2009 19:54:52 -0500 (EST)
To: [e-mail]
Subject: [IETF Meeting Session Request Tool] sasl - New Meeting Session Request for IETF 74
From: Tom Yu <[e-mail]>
Date: Mon, 19 Jan 2009 19:54:52 -0500
Message-ID: <[e-mail]>
Lines: 52
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>

--=-=-=

Please let me know if I should revise the conflict list.


--=-=-=
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; Mon, 19 Jan 2009 19:50:50 -0500
X-Sieve: CMU Sieve 2.2
Received: from pacific-carrier-annex.mit.edu by po9.mit.edu (8.13.6/4.7) id n0K0onEn029012; Mon, 19 Jan 2009 19:50:50 -0500 (EST)
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114])
	by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n0K0oilm022546
	for <[e-mail]>; Mon, 19 Jan 2009 19:50:44 -0500 (EST)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
	by mit.edu (Spam Firewall) with ESMTP id B46A8122B757
	for <[e-mail]>; Mon, 19 Jan 2009 19:50:22 -0500 (EST)
Received: by core3.amsl.com (Postfix, from userid 30)
	id EF4653A6A86; Mon, 19 Jan 2009 16:50:36 -0800 (PST)
From: IETF Meeting Session Request Tool <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail]
Subject: sasl - New Meeting Session Request for IETF 74 
Message-Id: <[e-mail]>
Date: Mon, 19 Jan 2009 16:50:36 -0800 (PST)
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Lines: 23
MIME-Version: 1.0

A new meeting session request has just been submitted
by Tom Yu, a working group chair of sasl.

---------------------------------------------------------
Working Group Name: sasl
Area Name: Security Area
Session Requester: Tom Yu

Number of Sessions: 1
Length of Session(s):  2 hours
                       
                       
Number of Attendees: 30
Conflicts to Avoid:
  First Priority: apparea saag sieve krb-wg kitten vcarddav
  Second Priority: dkim emu eai pkix
  Third Priority: httpbis idnabis lemonade smime tls

Special Requests:
  second video projector and screen, and additional microphones, as we and kitten and krb-wg have done in the past
---------------------------------------------------------



--=-=-=--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0JGs1ho052753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 09:54:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0JGs1AC052752; Mon, 19 Jan 2009 09:54:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0JGrnfO052731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 19 Jan 2009 09:54:00 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n0JGrj7Z002145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 11:53:46 -0500 (EST)
Date: Mon, 19 Jan 2009 11:53:45 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, Abhijit Menon-Sen <[e-mail]>, Chris Newman <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Sunday, January 18, 2009 09:48:07 PM +0000 Alexey Melnikov 
<[e-mail]> wrote:

>
> Hi,
> This is a minor issue with existing SCRAM ABNF:
>
>> saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>                            ;; Conforms to <value>
>>
>> value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>                               UTF8-2 / UTF-3 / UTF8-4
>> ;; UTF8-char except CTL, "=", and ",".
>>
>> authzid         = "a=" saslname
>
> Authorization identity is protocol specific, so I don't think the
> document should disallow US-ASCII CTLs in it.
> So, any objections of changing "value-safe-char" to be any UTF-8 encoded
> Unicode character except for NUL (which is universally disallowed), "="
> and ","?

Sounds good to me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0JBqBtu036007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 04:52:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0JBqBUe036006; Mon, 19 Jan 2009 04:52:11 -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 n0JBq8Fi035998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 19 Jan 2009 04:52:10 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LOsfm-0002Uw-D4; Mon, 19 Jan 2009 12:52:07 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Abhijit Menon-Sen <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090119:[e-mail]::UezcfkCAQveRTF7k:2lkG
X-Hashcash: 1:22:090119:[e-mail]::Rrw4ix2My+q7Cl8z:8+vz
X-Hashcash: 1:22:090119:[e-mail]::CgNzdFJKYeti1RgC:BmbK
X-Hashcash: 1:22:090119:[e-mail]::vgZPKBuyds/yBDiI:Fc9e
Date: Mon, 19 Jan 2009 12:52:05 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Mon, 19 Jan 2009 11:27:18 +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.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <[e-mail]> writes:
>>  
>>
>>>Hi,
>>>This is a minor issue with existing SCRAM ABNF:
>>>    
>>>
>>>>saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>>>                           ;; Conforms to <value>
>>>>
>>>>value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>>>                              UTF8-2 / UTF-3 / UTF8-4
>>>>;; UTF8-char except CTL, "=", and ",".
>>>>
>>>>authzid         = "a=" saslname
>>>>      
>>>>
>>>Authorization identity is protocol specific, so I don't think the
>>>document should disallow US-ASCII CTLs in it.
>>>So, any objections of changing "value-safe-char" to be any UTF-8
>>>encoded Unicode character except for NUL (which is universally
>>>disallowed), "=" and ","?
>>>    
>>>
>>I think per RFC 4422 you should only exclude NUL.
>>  
>>
> Yes.
> But "=" and "," are special characters in SCRAM, so they are encoded
> as "=2C" and "=3D".

Ok, if all non-NUL characters are escaped, I don't see a problem.  +1
from me.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0JBRbbw034921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 04:27:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0JBRbRs034920; Mon, 19 Jan 2009 04:27: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 n0JBRQrH034906 for <[e-mail]>; Mon, 19 Jan 2009 04:27:37 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.115.70] (92.40.115.70.sub.mbb.three.co.uk [92.40.115.70])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 19 Jan 2009 11:27:25 +0000
Message-ID: <[e-mail]>
Date: Mon, 19 Jan 2009 11:27:18 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Simon Josefsson <[e-mail]>
CC: Abhijit Menon-Sen <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>Hi,
>>This is a minor issue with existing SCRAM ABNF:
>>    
>>
>>>saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>>                           ;; Conforms to <value>
>>>
>>>value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>>                              UTF8-2 / UTF-3 / UTF8-4
>>>;; UTF8-char except CTL, "=", and ",".
>>>
>>>authzid         = "a=" saslname
>>>      
>>>
>>Authorization identity is protocol specific, so I don't think the
>>document should disallow US-ASCII CTLs in it.
>>So, any objections of changing "value-safe-char" to be any UTF-8
>>encoded Unicode character except for NUL (which is universally
>>disallowed), "=" and ","?
>>    
>>
>I think per RFC 4422 you should only exclude NUL.
>  
>
Yes.
But "=" and "," are special characters in SCRAM, so they are encoded as 
"=2C" and "=3D".



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0JBOP8q034824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2009 04:24:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0JBOPDH034823; Mon, 19 Jan 2009 04:24: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 n0JBOBWU034814 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 19 Jan 2009 04:24:24 -0700 (MST) (envelope-from [e-mail])
Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from <[e-mail]>) id 1LOsEa-0002Ub-1y; Mon, 19 Jan 2009 12:24:01 +0100
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Abhijit Menon-Sen <[e-mail]>, Chris Newman <[e-mail]>, [e-mail]
Subject: Re: Allowed characters in SCRAM authentication/authorization identities
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090119:[e-mail]::6jqeSEJpp+/hPfKy:2kCj
X-Hashcash: 1:22:090119:[e-mail]::hx8Q5zWZnWM7Jh9i:7bWo
X-Hashcash: 1:22:090119:[e-mail]::dsQQHRnDdOrea3aw:IQMe
X-Hashcash: 1:22:090119:[e-mail]::K/RWx30zmyuJb6Le:XlGQ
Date: Mon, 19 Jan 2009 12:23:55 +0100
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Sun, 18 Jan 2009 21:48:07 +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.5 (2008-06-10) host=yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Hi,
> This is a minor issue with existing SCRAM ABNF:
>
>> saslname        = 1*(value-safe-char / "=2C" / "=3D")
>>                            ;; Conforms to <value>
>>
>> value-safe-char = %20-2B / %2D-3C / %3E-7E /
>>                               UTF8-2 / UTF-3 / UTF8-4
>> ;; UTF8-char except CTL, "=", and ",".
>>
>> authzid         = "a=" saslname
>
> Authorization identity is protocol specific, so I don't think the
> document should disallow US-ASCII CTLs in it.
> So, any objections of changing "value-safe-char" to be any UTF-8
> encoded Unicode character except for NUL (which is universally
> disallowed), "=" and ","?

I think per RFC 4422 you should only exclude NUL.

3.4.1.  Authorization Identity String

   The authorization identity string is a sequence of zero or more
   Unicode [Unicode] characters, excluding the NUL (U+0000) character,
   representing the identity to act as.
...

   While the character encoding schema used to transfer the
   authorization identity string in the authentication exchange is
   mechanism specific, mechanisms are expected to be capable of carrying
   the entire Unicode repertoire (with the exception of the NUL
   character).

/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 n0ILn8FM098148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jan 2009 14:49:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0ILn8wC098147; Sun, 18 Jan 2009 14:49:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ILmt6f098121 for <[e-mail]>; Sun, 18 Jan 2009 14:49:07 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.161.173] (92.40.161.173.sub.mbb.three.co.uk [92.40.161.173])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 18 Jan 2009 21:48:53 +0000
Message-ID: <[e-mail]>
Date: Sun, 18 Jan 2009 21:48:07 +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: Abhijit Menon-Sen <[e-mail]>, Chris Newman <[e-mail]>
CC: [e-mail]
Subject: Allowed characters in SCRAM authentication/authorization identities
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>

Hi,
This is a minor issue with existing SCRAM ABNF:

> saslname        = 1*(value-safe-char / "=2C" / "=3D")
>                            ;; Conforms to <value>
>
> value-safe-char = %20-2B / %2D-3C / %3E-7E /
>                               UTF8-2 / UTF-3 / UTF8-4
> ;; UTF8-char except CTL, "=", and ",".
>
> authzid         = "a=" saslname

Authorization identity is protocol specific, so I don't think the 
document should disallow US-ASCII CTLs in it.
So, any objections of changing "value-safe-char" to be any UTF-8 encoded 
Unicode character except for NUL (which is universally disallowed), "=" 
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 n08F1IIf050546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 08:01:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08F1Ipx050545; Thu, 8 Jan 2009 08:01:18 -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 n08F1HNI050538 for <[e-mail]>; Thu, 8 Jan 2009 08:01:17 -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 6C09A4AC6A; Thu,  8 Jan 2009 16:01:16 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231426876-75452-1/6/7 (2 recipients); Thu, 8 Jan 2009 16:01:16 +0100
Message-Id: <[e-mail]>
Date: Thu, 8 Jan 2009 16:01:21 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: gs2 hashed oids
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>

Jeffrey Hutzelman writes:
> Yes, but the SASL and GS2 implementation need not worry about this; 
> all they should need to do is call GSS_Indicate_mechs(), whose result 
> will include any composite mechanisms which are part of the default 
> set.  Or, it may use GSS_Indicate_mechs_by_mech_attrs() to list 
> mechanisms (including composite mechanisms) which have the attributes 
> GS2 requires.

I see. But then a different problem appears. It sounds as if the list 
may be long.

IMAP servers are required to return a list of available SASL mechanism 
on a single line, and that line shouldn't be too long. The relevant RFC 
cautions against lines longer than 8k, which gives space for about 350 
GS2 names after subtracting syntax and some other stuff, so I assume 
that problems will appear somewhere between 100 and 1000 GS2 mechanism 
stacks.

Other protocols (or common deployed implementations) may have limits, 
but I don't care to research that now, so I'll just take 100-1000.

How likely are 100-1000 OIDs? Unthinktable, possible, unusual or common?

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 n08EhXZW049499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 07:43:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08EhXMR049498; Thu, 8 Jan 2009 07:43:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08EhWrU049492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 8 Jan 2009 07:43:33 -0700 (MST) (envelope-from [e-mail])
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n08EhU6H006121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 09:43:30 -0500 (EST)
Date: Thu, 08 Jan 2009 09:43:30 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: gs2 hashed oids
Message-ID: <[e-mail]>
In-Reply-To: <IOhp6hv/VOc/CVi5/[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <IOhp6hv/VOc/CVi5/[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, January 08, 2009 02:39:34 PM +0100 Arnt Gulbrandsen 
<[e-mail]> wrote:

>
> Jeffrey Hutzelman writes:
>> Stackable pseudo-mechanisms are not the same as multi-level negotiation.
>> Multi-level negotiation is a problem because you end up having to
>> agree on one level before knowing if there's a mutually-acceptable
>> mechanism at the next.  But stackable mechanisms don't work that way;
>> every possible stack has an OID, composed from the OID's of the
>> stacked mechanisms (see section 4.1 of
>> draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire
>> _stack_ is negotiated at once, as if it were a single mechanism.
>> This leads to an explosion of possible mechanism OID's, where it's
>> not entirely possible to predict what they all are, but is entirely
>> unreasonable to expect every combination to be named and registered.
>
> It sounds as though a server asked to use GS2-GQGFDSAGDSAF would have to
> recurse through all possible mechanism stack

Yes, but the SASL and GS2 implementation need not worry about this; all 
they should need to do is call GSS_Indicate_mechs(), whose result will 
include any composite mechanisms which are part of the default set.  Or, it 
may use GSS_Indicate_mechs_by_mech_attrs() to list mechanisms (including 
composite mechanisms) which have the attributes GS2 requires.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08DdhwE044680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 06:39:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08DdhVZ044679; Thu, 8 Jan 2009 06:39:43 -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 n08DdVmb044670 for <[e-mail]>; Thu, 8 Jan 2009 06:39:42 -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 55AEE4AC68; Thu,  8 Jan 2009 14:39:30 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231421970-75452-1/6/5 for [e-mail]; Thu, 8 Jan 2009 14:39:30 +0100
Message-Id: <IOhp6hv/VOc/CVi5/[e-mail]>
Date: Thu, 8 Jan 2009 14:39:34 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: gs2 hashed oids
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman writes:
> Stackable pseudo-mechanisms are not the same as multi-level negotiation.
> Multi-level negotiation is a problem because you end up having to 
> agree on one level before knowing if there's a mutually-acceptable 
> mechanism at the next.  But stackable mechanisms don't work that way; 
> every possible stack has an OID, composed from the OID's of the 
> stacked mechanisms (see section 4.1 of 
> draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire 
> _stack_ is negotiated at once, as if it were a single mechanism.  
> This leads to an explosion of possible mechanism OID's, where it's 
> not entirely possible to predict what they all are, but is entirely 
> unreasonable to expect every combination to be named and registered.

It sounds as though a server asked to use GS2-GQGFDSAGDSAF would have to 
recurse through all possible mechanism stack, encoding its OID as 
described in the kitten draft, hashing the resulting OID and comparing 
it against the desired name. Have I understood it correctly? (If not, 
then maybe it's nonobvious and should be explained in the GS2 
document.) If I have, then is that practical to recurse through the 
tree to find the mechanism?

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 n07NGhTc005474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 16:16:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07NGhIw005473; Wed, 7 Jan 2009 16:16:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07NGWHT005467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 7 Jan 2009 16:16:43 -0700 (MST) (envelope-from [e-mail])
Received: from 68-246-165-160.pools.spcsdns.net (68-247-50-215.pools.spcsdns.net [68.247.50.215]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n07NGPpd002028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 18:16:28 -0500 (EST)
Date: Wed, 07 Jan 2009 18:16:25 -0500
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Sam Hartman <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: gs2 hashed oids
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.185.41
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, January 06, 2009 11:45:47 PM +0100 Simon Josefsson 
<[e-mail]> wrote:

> I have two relatively mild concerns.
>
> The first concern is that the quality of non-standard GSS-API mechanisms
> are sometimes low, so it may open up for security problems in SASL if
> such mechanisms become available automatically.

This is a classic conceit.  Our concern that a particular non-standard 
mechanism might be insecure and make "our protocol" insecure is really 
completely irrelevant to the operator who uses that mechanism as his 
enterprise authentication mechanism.  Choice of mechanisms is a policy 
decision, and our role as protocol designers and implementors is not to set 
policy(*).

> I believe GS2 would
> need a security consideration that explains this.

I certainly think we need to say that the security of GS2 depends on the 
security properties of the particular underlying GSS-API mechanism used, 
and in what ways.  I don't think we need to or should say "WARNING: don't 
use non-standard mechanisms, because they are low quality" or similar FUD.


> Another concern is that the hashed OID makes the mechanism names harder
> to read for humans.  Ordinary users do chose between CRAM-MD5 and
> DIGEST-MD5 in mail applications today.  I would fear a usability review
> of a user interface that asks the users to chose between
> GS2-DT4PIK22T6EPV2PY and GS2-QLJHGJLWNPLNQRNK.

I would, too, if I had designed that user interface.  But given the choice 
between an implementation which showed a user-friendly mechanism name like 
"GSS-API with Kerberos" or "GSS-API with public keys" for mechanisms it 
knows about  and a hashed named for others, and one which showed names like 
"GS2-KERBEROS" or "GS2-SPKM" for mechanisms it knows about and doesn't let 
me use other mechanisms at all, I'd pick the former every time.


> There is a relatively easy solution to both these concerns: require that
> a name is registered with IANA for every GSS-API mechanism that is
> intended for use in SASL.  This is not too onerous IMHO, since the
> registration approach is First-Come-First-Serve.

It is, because random enterprises don't know or care about the IETF or IANA 
or want to have to register their private mechanisms with someone before 
they can use them.  It's also unnecessary to impose such a requirement.


\>> I think it is also important that we support dynamic stackable
>> pseudo-mechanisms, which means we need to have some solution for
>> mechanisms that cannot be registered.
>
> This seems like a separate issue, and potentially a problematic one: how
> do we avoid interop problems if mechanism X is negotiated under
> pseudo-mechanism Y or pseudo-mechanism Z or directly as X?  GS2 contains
> text about GSS-API mechanisms that negotiates other mechanisms now, but
> it seems the same concern also applies to pseudo-mechanisms.

Stackable pseudo-mechanisms are not the same as multi-level negotiation.
Multi-level negotiation is a problem because you end up having to agree on 
one level before knowing if there's a mutually-acceptable mechanism at the 
next.  But stackable mechanisms don't work that way; every possible stack 
has an OID, composed from the OID's of the stacked mechanisms (see section 
4.1 of draft-ietf-kitten-stackable-pseudo-mechs-02.txt).  Then the entire 
_stack_ is negotiated at once, as if it were a single mechanism.  This 
leads to an explosion of possible mechanism OID's, where it's not entirely 
possible to predict what they all are, but is entirely unreasonable to 
expect every combination to be named and registered.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07Bjjm1068779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 04:45:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07Bjjvc068778; Wed, 7 Jan 2009 04:45:45 -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 n07BjiKQ068771 for <[e-mail]>; Wed, 7 Jan 2009 04:45:44 -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 784154AC44; Wed,  7 Jan 2009 12:45:43 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231328743-64703-1/6/3 (2 recipients); Wed, 7 Jan 2009 12:45:43 +0100
Message-Id: <[e-mail]>
Date: Wed, 7 Jan 2009 12:45:46 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: gs2 hashed oids
References: <[e-mail]> <[e-mail]> <twNA6KE/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson writes:
> Arnt Gulbrandsen <[e-mail]> writes:
>> Side note: Would it be permissible at all to use GSS-API 
>> experimenta/non-standard mechanisms in SASL without an X- prefix?
>
> The registration model described in RFC 4422 -- first come first 
> serve, with no technical review -- appears to permit almost any 
> mechanism in SASL, not just standardized mechanisms. I don't see a 
> difference between a GSS-API mechanism and a SASL mechanism in this 
> context.

OK

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n07BJSwi067614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 04:19:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07BJSGU067613; Wed, 7 Jan 2009 04:19:28 -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 n07BJFTg067600 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 7 Jan 2009 04:19:27 -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 1LKWRL-0000nD-Lx; Wed, 07 Jan 2009 12:19:11 +0100
From: Simon Josefsson <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Subject: Re: gs2 hashed oids
References: <[e-mail]> <[e-mail]> <twNA6KE/[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090107:[e-mail]::gA4+LkH1GVltyKp3:JmS4
X-Hashcash: 1:22:090107:[e-mail]::GCJY3rjZVxTmDDZ6:J1By
Date: Wed, 07 Jan 2009 12:19:11 +0100
In-Reply-To: <twNA6KE/[e-mail]> (Arnt Gulbrandsen's message of "Wed, 7 Jan 2009 12:06:36 +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>

Arnt Gulbrandsen <[e-mail]> writes:

> Simon Josefsson writes:
>> There is a relatively easy solution to both these concerns: require
>> that a name is registered with IANA for every GSS-API mechanism that
>> is intended for use in SASL. This is not too onerous IMHO, since the
>> registration approach is First-Come-First-Serve. There are X-* 
>> mechanism names for those who only wants to experiment.
>
> Side note: Would it be permissible at all to use GSS-API
> experimenta/non-standard mechanisms in SASL without an X- prefix?

The registration model described in RFC 4422 -- first come first serve,
with no technical review -- appears to permit almost any mechanism in
SASL, not just standardized mechanisms.  I don't see a difference
between a GSS-API mechanism and a SASL mechanism in this context.

/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 n07B6a6b066783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 04:06:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07B6asl066782; Wed, 7 Jan 2009 04:06:36 -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 n07B6YoT066776 for <[e-mail]>; Wed, 7 Jan 2009 04:06:34 -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 9B2D94AC44; Wed,  7 Jan 2009 12:06:33 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231326393-64703-1/6/2 (2 recipients); Wed, 7 Jan 2009 12:06:33 +0100
Message-Id: <twNA6KE/[e-mail]>
Date: Wed, 7 Jan 2009 12:06:36 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: gs2 hashed oids
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>

Simon Josefsson writes:
> There is a relatively easy solution to both these concerns: require 
> that a name is registered with IANA for every GSS-API mechanism that 
> is intended for use in SASL. This is not too onerous IMHO, since the 
> registration approach is First-Come-First-Serve. There are X-* 
> mechanism names for those who only wants to experiment.

Side note: Would it be permissible at all to use GSS-API 
experimenta/non-standard mechanisms in SASL without an X- prefix?

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 n07B54Es066685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 04:05:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n07B54UA066684; Wed, 7 Jan 2009 04:05:04 -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 n07B4qMt066666 for <[e-mail]>; Wed, 7 Jan 2009 04:05:03 -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 2CF574AC44; Wed,  7 Jan 2009 12:04:51 +0100 (CET)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1231326290-64703-1/6/2 for [e-mail]; Wed, 7 Jan 2009 12:04:50 +0100
Message-Id: <[e-mail]>
Date: Wed, 7 Jan 2009 12:04:53 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: gs2 hashed oids
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8; 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>

Sam Hartman:
>>  Like Jeff Hutzelman I believe that it is important to be able to use=20
>>  a GSS-API mechanism in an application that has never heard of that=20
>>  mechanism.

(Why is this important?)

>>  We have significant evidence from SAP R3 this can be made to work=20
>>  and evidence from other applications that it is valuable in those=20
>>  contexts.

(Do tell?)

>>  I don't understand why people think this would be a bad idea, and=20
>>  would be happy to discuss.

1. Some application developers (quite a few in my experience =E2=80=94 I =
was a=20
library person in a past life) really don't want customers to use=20
something they haven't tested, and do not want to have unknown plugins=20
loaded at the customer or unknown mechanisms used there. Do you know=20
the old saying "fly what you test and test what you fly"?

2. Some application developers (mostly the same set as above, but not=20
quite) want the ability to reproduce what the customers are seeing.=20
Using something unknown to the application is problematic. (There are=20
also other problems, of course.)

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 n06Mk5ro032118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 15:46:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n06Mk5kx032117; Tue, 6 Jan 2009 15:46:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 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 n06Mjq8a032099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 6 Jan 2009 15:46:04 -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 1LKKgG-0007mF-D1; Tue, 06 Jan 2009 23:45:49 +0100
From: Simon Josefsson <[e-mail]>
To: Sam Hartman <[e-mail]>
Cc: [e-mail]
Subject: Re: gs2 hashed oids
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090106:[e-mail]::xYYypeL36Utgqo3O:7QYT
X-Hashcash: 1:22:090106:[e-mail]::MfLf47J9MR3sYC/H:9Zt7
Date: Tue, 06 Jan 2009 23:45:47 +0100
In-Reply-To: <[e-mail]> (Sam Hartman's message of "Tue, 06 Jan 2009 08:18:22 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.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>

Sam Hartman <[e-mail]> writes:

> Like Jeff Hutzelman I believe that it is important to be able to use a
> GSS-API mechanism in an application that has never heard of that
> mechanism.  We have significant evidence from SAP R3 this can be made
> to work and evidence from other applications that it is valuable in
> those contexts.  I don't understand why people think this would be a
> bad idea, and would be happy to discuss.

I have two relatively mild concerns.

The first concern is that the quality of non-standard GSS-API mechanisms
are sometimes low, so it may open up for security problems in SASL if
such mechanisms become available automatically.  I believe GS2 would
need a security consideration that explains this.

Another concern is that the hashed OID makes the mechanism names harder
to read for humans.  Ordinary users do chose between CRAM-MD5 and
DIGEST-MD5 in mail applications today.  I would fear a usability review
of a user interface that asks the users to chose between
GS2-DT4PIK22T6EPV2PY and GS2-QLJHGJLWNPLNQRNK.

There is a relatively easy solution to both these concerns: require that
a name is registered with IANA for every GSS-API mechanism that is
intended for use in SASL.  This is not too onerous IMHO, since the
registration approach is First-Come-First-Serve.  There are X-*
mechanism names for those who only wants to experiment.

However, this is merely my preference, and I don't feel strongly about
it.  I can live with hashed OIDs too, and will propose text for the
security considerations about this point.

> I think it is also important that we support dynamic stackable
> pseudo-mechanisms, which means we need to have some solution for
> mechanisms that cannot be registered.

This seems like a separate issue, and potentially a problematic one: how
do we avoid interop problems if mechanism X is negotiated under
pseudo-mechanism Y or pseudo-mechanism Z or directly as X?  GS2 contains
text about GSS-API mechanisms that negotiates other mechanisms now, but
it seems the same concern also applies to pseudo-mechanisms.

/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 n06DIkrh001438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2009 06:18:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n06DIk3U001437; Tue, 6 Jan 2009 06:18:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n06DIZjO001424 for <[e-mail]>; Tue, 6 Jan 2009 06:18:46 -0700 (MST) (envelope-from [e-mail])
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B4D12451B; Tue,  6 Jan 2009 08:18:22 -0500 (EST)
From: Sam Hartman <[e-mail]>
To: [e-mail]
Subject: gs2 hashed oids
Date: Tue, 06 Jan 2009 08:18:22 -0500
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.  Nico, thanks for conveying my concern.  I'm really sorry that I
was so busy, but my consulting practice and the nomcom have taken up
all my time lately.

Like Jeff Hutzelman I believe that it is important to be able to use a
GSS-API mechanism in an application that has never heard of that
mechanism.  We have significant evidence from SAP R3 this can be made
to work and evidence from other applications that it is valuable in
those contexts.  I don't understand why people think this would be a
bad idea, and would be happy to discuss.  If I'm not sufficiently
responsive here please IM or send me personal mail.

I believe the same arguments apply to SASL and I definitely want to
use SASL mechanisms with applications that have not been intended to
use the mechanisms I've using.  I've done this with many applications
that use the Cyrus framework at least on the client and it has been
incredibly valuable in several deployments.

I think it is critical we avoid situations where a SASL mechanism has
multiple names.

I think the OS distributor arguments that Jeff brings up are quite
valid.

My strong preference is to keep hashed oid names.

If we cannot get a consensus to do that, we should fall back to
something.  I think it would be a very bad idea to give scram and
Kerberos names but not have a plan for how we can do the same in the
future.  If there are sufficient pressures that we cannot get
consensus behind hashed oid names, then we should get something that
will work long-term, not adopt a solution for scram and kerberos only
to have the fight again later with deployed code blocking our options.

So, my preference is to get consensus that hashed oid names are
acceptable.  If that fails, we should design a mechanism that will
allow us to assign names to mechanisms but that will handle the OS
distribution problems.

I think it is also important that we support dynamic stackable
pseudo-mechanisms, which means we need to have some solution for
mechanisms that cannot be registered.