Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 17 January 2007 18:47 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HIluCX082562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 11:47:56 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l0HIluQw082560; Wed, 17 Jan 2007 11:47:56 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l0HIltQc082549; Wed, 17 Jan 2007 11:47:55 -0700 (MST) (envelope-from alexey.melnikov@isode.com)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <Ra5vWgBD3Tiu@rufus.isode.com>; Wed, 17 Jan 2007 18:47:54 +0000
Message-ID: <45AE6F4C.4020903@isode.com>
Date: Wed, 17 Jan 2007 18:47:40 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
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
MIME-Version: 1.0
To: Frank Ellermann <nobody@xyzzy.claranet.de>
CC: ietf-sasl@imc.org, ietf-pop3ext@imc.org
Subject: Re: Fwd: "POP3 SASL Authentication Mechanism" submitted for publication
References: <200701150450.l0F4of78001138@boole.openldap.org> <45AB62E1.8030408@isode.com> <45ABD87A.4392@xyzzy.claranet.de>
In-Reply-To: <45ABD87A.4392@xyzzy.claranet.de>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Frank Ellermann wrote:

>Alexey Melnikov wrote:
>  
>
>>>>The multi-line response client to server confuse me.  
>>>>Which SASL mechanism needs this ?
>>>>        
>>>>
>>>There's no multi-line response (unless I'm missing something).
>>>      
>>>
>>Indeed.
>>There are mechanisms with multiple challenges/responses.
>>    
>>
>Let's see, I hope I got it now.  What really happens is this:
>
>C: AUTH mech initial-response-if-allowed-for-mech
>S: + challenge
>C: response
>S: + challenge
>C: response
>S: +OK your're logged in, maibox locked, have fun
>  
>
Correct.

>However the ABNF put's the complete part of the client into one
><auth-command> = "AUTH" mech [SP ir] *( CRLF [base64]) CRLF
>
>My confusion was that I thought the client sends this complete
>multi-line <auth-command> at once, without intervening server
>challenges.
>  
>
Right.

>Maybe it's only me, then forget it.  Otherwise the ABNF has a
><continue-req> for the "+" SP [base64] CRLF from the server,
>it could similarl also define a <continue-response>:
>
>auth-command     = "AUTH" mech [initial-response] CRLF *(response)
>initial-response = SP (base64 / "=")   ; a single "=" if empty
>response         = [base64] CRLF       ; after server challenge
>  
>
I don't object to something like this.

>  [Abhijit Menon-Sen wrote:]
>  
>
>>>there's no very good way to express this in the ABNF
>>>      
>>>
>Yes, but maybe using an explicit <response> with a comment helps.
>
>For Hector's multi-line observation I'm not sure what that was,
>an implementor confused like me, or some kind of pipelining.
>  
>