mailing list archives

I'm trying to figure out exactly how to implement PLAIN authentication
for IMAP.  The spec seems less than clear to me.  The example given in
RFC 2595, which is not for IMAP, illustrates a PLAIN exchange thusly:

C: a003 AUTHENTICATE "PLAIN" {21+}
C: <NUL>tim<NUL>tanstaaftanstaaf

That is, it's one message, giving two parameters, "PLAIN" and the
authentication information.

However, when I advertise AUTH=PLAIN, Thunderbird sends

C: 4 authenticate plain

without any authentication information.  This is in accord with the
general description of the AUTHENTICATE message in RFC 3501, and with
the examples of non-PLAIN authentication given in RFC 3501, but not in
accord with RFC 2595, which explicitly says "a single message", or with
the example given.

Bill

On Fri, 25 Jan 2008, Bill Janssen wrote:
> The example given in
> RFC 2595, which is not for IMAP, illustrates a PLAIN exchange thusly:
> C: a003 AUTHENTICATE "PLAIN" {21+}
> C: <NUL>tim<NUL>tanstaaftanstaaf
> That is, it's one message, giving two parameters, "PLAIN" and the
> authentication information.

It is a mistake to assume that an example for ACAP has any relationship to 
IMAP.  It does not.

The other, more basic, mistake is in using to obsolete documents. 
Please refer to:
 	RFC 3501	documentation on the syntax of the AUTHENTICATE
 			 command in IMAP
 	RFC 4422	documentation of the SASL framework
 	RFC 4616	documentation of the PLAIN extension
 	RFC 4959	documentation of the SASL-IR extension in IMAP

Within the framework of SASL (RFC 4422), there is an identification of the 
mechansim and a challenge/response exchange.  Depending upon the 
mechanism, the challenge/response exchange may start with a challenge or a 
response.

The protocol used determines the syntax by how this works; thus the 
determination of the syntax of SASL in IMAP is by IMAP (RFC 3501).  IMAP 
assumes an initial server challenge, so with a mechanism such as PLAIN 
(RFC 4616) that requires an initial client response, the server MUST send 
an empty initial server challenge in response to an AUTHENTICATE PLAIN 
command in IMAP.

Last, and absolutely least, RFC 4959 details a way that the initial 
response can be sent in the AUTHENTICATE command IF, AND ONLY IF, the 
server allows that facility.  Note that the client is under no obligation 
to use that facility even if the server allows it.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

> Please refer to:
>  	RFC 3501	documentation on the syntax of the AUTHENTICATE
>  			 command in IMAP
>  	RFC 4422	documentation of the SASL framework
>  	RFC 4616	documentation of the PLAIN extension
>  	RFC 4959	documentation of the SASL-IR extension in IMAP

Thanks, that's what I needed.

Bill

On Sat Jan 26 00:22:56 2008, Mark Crispin wrote:
> Last, and absolutely least, RFC 4959 details a way that the initial  
> response can be sent in the AUTHENTICATE command IF, AND ONLY IF,  
> the server allows that facility.  Note that the client is under no  
> obligation to use that facility even if the server allows it.

ACAP always offers this facility, but likewise does not mandate that  
clients avail themselves of it - it cannot, in fact; there's text in  
the SASL base spec saying so. So Mark's note above could be clarified  
  further by adding "[...] and the client understands the extension".  
(That said, where the server offers it and the client does understand  
it, it's likely to be used wherever possible - it's a most trivial  
extension on both ends).

ACAP's challenges and responses are binary, not base64 encoded, so  
it's very often used in SASL mechanism examples for readability,  
since it's the only SASL profile which does this in a text-based  
protocol.

ACAP can also supply completion data on success - a final SASL  
response in the tagged OK response - and I seem to remember seeing  
occasional examples in documents showing IMAP doing the same, but  
I've never found a specification saying so - I suspect this is a case  
of people transcribing examples from ACAP to IMAP in order to use a  
more popular protocol. A minor case of caveat lector - the examples  
can be wrong.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On Fri, 25 Jan 2008, Bill Janssen wrote:
>> Please refer to:
>>  	RFC 3501	documentation on the syntax of the AUTHENTICATE
>>  			 command in IMAP
>>  	RFC 4422	documentation of the SASL framework
>>  	RFC 4616	documentation of the PLAIN extension
>>  	RFC 4959	documentation of the SASL-IR extension in IMAP
> Thanks, that's what I needed.

Good luck!

Proper understanding of how all this works requires carefully going 
through RFC 3501 section 6.2.2, and all of RFC 4422 and RFC 4616.

Hopefully, though, you'll find it to be more understandable than the 
earlier documents.

Don't worry about RFC 4919 until the very end.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

> Good luck!
> 
> Proper understanding of how all this works requires carefully going 
> through RFC 3501 section 6.2.2, and all of RFC 4422 and RFC 4616.

From 6.2.2 of 3501:

      A server challenge consists of a 
      command continuation request response with the "+" token followed 
      by a BASE64 encoded string.  The client response consists of a 
      single line consisting of a BASE64 encoded string.  If the client 
      wishes to cancel an authentication exchange, it issues a line 
      consisting of a single "*".  If the server receives such a 
      response, it MUST reject the AUTHENTICATE command by sending a 
      tagged BAD response. 

So I believe that a plain authentication challenge should look something
like this (for valid account with username "janssen", password "foo"):

C: 4 authenticate plain\r\n
S: +\r\n
C: AGphbnNzZW4AZm9v\r\n
S: 4 OK authenticate\r\n

D'accord?

But what I see (from Thunderbird) is

C: 4 authenticate plain\r\n
S: +\r\n
C: AGphbnNzZW4AZm9v

so my server never knows when to stop waiting for the client to send
more data...

Bill

On Fri, 25 Jan 2008, Bill Janssen wrote:
...
> So I believe that a plain authentication challenge should look something
> like this (for valid account with username "janssen", password "foo"):
>
> C: 4 authenticate plain\r\n
> S: +\r\n
> C: AGphbnNzZW4AZm9v\r\n
> S: 4 OK authenticate\r\n
>
> D'accord?

Nope.  You didn't check the syntax for a command continuation request 
response.  On page 84 of RFC 3501 we find:

continue-req    = "+" SP (resp-text / base64) CRLF

I.e., the space after the plus-sign is mandatory, even when the base64 is 
empty.  So make the first server line above:
  S: + \r\n

The rest of that looks correct to me.

As a side-note, the server should consider including in the tagged OK 
response to AUTHENTICATE a CAPABILITY response code that lists the 
capaibilities that are useful after authentication.  e.g.,

  S: 4 OK [CAPABILITY IMAP4rev1 IDLE MULTIAPPEND X-MOTTO] Authentication succeeded\r\n

(c.f. section 6.2.2p9 for details and when not bother)


Philip Guenther

> But what I see (from Thunderbird) is
> 
> C: 4 authenticate plain\r\n
> S: +\r\n
> C: AGphbnNzZW4AZm9v
> 
> so my server never knows when to stop waiting for the client to send
> more data...

Ah!  Got it.  T-bird was sending the right thing; my server framework was
eating the CRLF.  Now the handshake looks like

C: 4 authenticate plain\r\n
S: + \r\n
C: AGphbnNzZW4AZm9v\r\n
S: 4 OK [CAPABILITY IMAP4rev1 NAMESPACE UIDPLUS AUTH=PLAIN] AUTHENTICATE completed\r\n

which I believe is correct.

Bill

> Nope.  You didn't check the syntax for a command continuation request 
> response.  On page 84 of RFC 3501 we find:
> 
> continue-req    = "+" SP (resp-text / base64) CRLF
> 
> I.e., the space after the plus-sign is mandatory, even when the base64 is 
> empty.  So make the first server line above:
>   S: + \r\n

Ah, thanks!

> As a side-note, the server should consider including in the tagged OK 
> response to AUTHENTICATE a CAPABILITY response code that lists the 
> capaibilities that are useful after authentication.  e.g.,
> 
>   S: 4 OK [CAPABILITY IMAP4rev1 IDLE MULTIAPPEND X-MOTTO] Authentication succeeded\r\n
> 
> (c.f. section 6.2.2p9 for details and when not bother)

OK, will do.

Bill