Dear Friends,

I have been working on one of the features I want to bring to curl, after the 7.34.0 release, which is really an extension of some of the work I have already performed in 7.34.0.

In 7.34 I added the ability to gracefully cancel an SASL authentication attempt should the client receive bad data from the server for a CRAM-MD5, DIGEST-MD5 and NTLM response rather than simple exiting.

If this was to happen, curl will exit with a CURLE_LOGIN_DENIED error after sending the relevant cancellation commands, even though the server may accept multiple mechanisms, such as LOGIN, PLAIN, CRAM-MD5, DIGEST-MD5 and NTLM (others such as GSSAPI are currently unsupported by the email protocols). The next step, which I have already coded up, is for curl to retry lesser mechanisms if the server advertises support for them which means that technically the following could happen:

NTLM requested
Bad response from server received
Client cancels
DIGEST-MD5 requested
Bad response from server received
Client cancels
CRAM-MD5 requested
Bad response from server received
Client cancels
LOGIN or PLAIN requested
User logged in or access denied

However, when I started to write the test harnesses last night I realised there is a possible problem with ftpserver.pl – which I’m not sure how to get around at present. I appreciate that not everyone here will be able to assist with this ☹

All the current IMAP, POP3 and SMTP authentication tests rely on the custom REPLY feature of the test server in order to specify the correct responses. However, the tests I need to add will have two responses each requiring a unique reply by the test server but for the same command (although sent separately by curl). That sounds a little confusing so let's imagine the following SMTP conversation:

C: EHLO
S: 250-Hello 192.168.0.1
S: 250-SIZE 10485760
S: 250-STARTTLS
S: 250-AUTH LOGIN NTLM
S: 250 CHUNKING
C: AUTH NTLM
S: 334 NTLM Accepted
C: NTLM <type-1 message>
S: 334 Complete and utter rubbish which the client won’t be able to decode
C: *
S: 501 AUTH cancelled by client
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: <base-64 encoded username>
S: 334 UGFzc3dvcmQ6
C: <base-64 encoded password>
S: 235 Authenticated

As can be seen with lines 7 and 13, the client sends the AUTH command with the appropriate SASL authentication mechanism. The first time requesting NTLM and the second time requesting LOGIN (after downgrading due to a bad NTLM type-2 response from the server). As such the test server needs to send different responses, but unfortunately, I can’t specify the following in a test case as ftpserver.pl currently stands:

<reply>
<servercmd>
AUTH LOGIN NTLM
REPLY AUTH 334 NTLM Accepted
REPLY AUTH 334 VXNlcm5hbWU6
</servercmd>
</reply>

...as I’m pretty sure the test server will send the second “334 VXNlcm5hbWU6” on both occasions (not 100% about this!) – and whilst this isn’t a problem for NTLM as it only processes the 334 part of the response the server would need to send a challenge for a AUTH CRAM-MD5 request.

Anyone have any ideas how we can get round this – I have started to code up support for authentication in ftpserver.pl (but haven't touched that code since August / September time) and isn’t really ready for general consumption as it stands :(

Thoughts and ideas are much appreciated.

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-12-03