749230 - TLS Certificate authentication violates IMAP specification (RFC 3501)

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[gmeyer]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.165 Safari/535.19

Steps to reproduce:

I have a courier IMAP server installed on Ubuntu 11.10 that requires TLS and client certificates for the purpose of authentication and identity.  Courier is configured to accept the EXTERNAL authentication method.

I have a client certificate associated to my mail account in Thunderbird 11.0.1.  I attempted to retrieve messages from my account on startup and subsequently by clicking "Get Mail"


Actual results:

Thunderbird successfully connects over SSL (port 993) and the mutual certificate exchange is successful.  Thunderbird then request the SASL EXTERNAL authentication method by sending the following command (traced with wireshark and SSL decoding using Courier's private key):

1 authenticate EXTERNAL Z20yNTUy

Thunderbird is attempting to pass an initial SALS response (using a BASE64 representation of the account username) with the requested SALS authentication method.  Although this is inline with RFC2222, the IMAP specification (RFC3501) specifically states the authentication command does not support sending an initial response.

-----------------  FROM RFC3501 ---------------

The AUTHENTICATE command does not support the optional "initial response" feature of [SASL].  Section 5.1 of [SASL] specifies how to handle an authentication mechanism which uses an initial response.
------------------------------------------------

Courier IMAP is rejecting the EXTERNAL authentication due to non compliance of syntax with the following response:

1 NO Login failed.


Expected results:

Thunderbird should only be sending the following IMAP command:

1 authenticate EXTERNAL

Thunderbird should then be waiting for a continuation command from the IMAP server, and then either send an empty initial response if the certificate should represent the account identity, or send a BASE64 representation of the username for the account identity.

Comment 1

[Joshua Cranmer [:jcranmer]]

What is the capabilities string of the IMAP server?
RFC 4959 <http://tools.ietf.org/html/rfc4959> allows for an initial response if SASL-IR is present.

Comment 2

[gmeyer]

CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=EXTERNAL AUTH=PLAIN ACL ACL2=UNION

Comment 3

[Joshua Cranmer [:jcranmer]]

Indeed, it looks like we should be checking for SASL-IR first.

Comment 4

[gmeyer]

Just as a point of clarification, is it against common practice to use only the certificate to identify the subject and not provide the username?  I could two potential uses cases and options:

1. The client certificate contains also contains the subject, so the initial challenge could be an empty string (let the server figure out how it to extract the subject from the certificate).

2. The client certificate is only used to authenticate, but the username would be used as the identity (current functionality).

Would it be a reasonable request to allow the account configuration to choose if the certificate should be used as the identity instead of supplying a username?  Stop me if I'm off my rocker.

Comment 5

[Ben Bucksch (:BenB)]

FWIW, the code is in
http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#5616

As for adding the capability, that needs the "bitflags" patch in bug 558659.

Comment 6

[Ben Bucksch (:BenB)]

Same is true for other auth schemes (in the same function)