Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » KMS does not handle "AUTH LOGIN username" as documented in RFC 2554
  •  
apittsley

Messages: 3
Karma: 0
Send a private message to this user
I tried to set up an IIS SMTP server which uses my KMS as a "smart host". I need this because the IIS server is behind a dynamic IP, therefore, email coming from it would be blocked, otherwise.

The IIS SMTP server needs to authenticate to KMS and the only option is "AUTH LOGIN". However, IIS SMTP places the username on the AUTH request. KMS ignores this username and instead uses the password as the username.

To make things worse, KMS reveals the password by logging a message that "password<_at_>domain.com" failed authentication.

Does anyone know of a way around this problem?
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
The LOGIN SASL mechanism is obsoleted in favor of the PLAIN SASL mechanism. Clients SHOULD implement the PLAIN SASL mechanism and use it whenever offered by a server. The LOGIN SASL mechanism SHOULD NOT be used by a client when other plaintext mechanisms are offered by a server.

According to IETF draft http://asg.web.cmu.edu/cyrus/download/sasl/draft-murchison-s asl-login-xx.txt (expired, obsolete), the server must send non-empty challenge first. Therefore, LOGIN authentication cannot use “initial-response” parameter:
Quote:


2.1. Client side of authentication protocol exchange

The client expects the server to issue a challenge. The client then
responds with the authorization identity. The client then expects
the server to issue a second challenge. The client then responds
with the authorization authenticator. The contents of both
challenges SHOULD be ignored.



Conclusion:
KMS DOES comply to RFC 2554. The client has a bug in SASL LOGIN mechanism implementation. Moreover, the client should use PLAIN instead of LOGIN.

As a workaround for incorrect implementation of SASL LOGIN authentication in client, you can disable LOGIN authentication method in Kerio MailServer (Advanced Options / Security Policy). LOGIN method will not be offered by SMTP server and SMTP client will use another authentication method (for example PLAIN).
  •  
apittsley

Messages: 3
Karma: 0
Send a private message to this user
I agree that the client should be updated. However, there is a reason why KMS allows authentication using the "login" method. Its so that obsolete clients can authenticate with that method.

RFC 2554 states that clients can send the initial response (username) in the AUTH request. This is not just for the "login" method, it is for any authentication method including "plain". If KMS does not handle this, then it does not comply with RFC 2554 as you claim.

BTW, the document you included a link to lists RFC 2554 in its references.
  •  
Pavel Dobry (Kerio)

Messages: 5245
Karma: 251
Send a private message to this user
apittsley wrote on Sun, 05 March 2006 08:04

I agree that the client should be updated. However, there is a reason why KMS allows authentication using the "login" method. Its so that obsolete clients can authenticate with that method.


Yes, they can authenticate if they use LOGIN method correctly.
Quote:


RFC 2554 states that clients can send the initial response (username) in the AUTH request. This is not just for the "login" method, it is for any authentication method including "plain". If KMS does not handle this, then it does not comply with RFC 2554 as you claim.


Correct. But this is valid only for authentication methods that sends empty initial response (RFC 2554):
Quote:

The optional initial-response argument to the AUTH command is
used to save a round trip when using authentication mechanisms
that are defined to send no data in the initial challenge.
When the initial-response argument is used with such a
mechanism, the initial empty challenge is not sent to the
client and the server uses the data in the initial-response
argument as if it were sent in response to the empty challenge.
Unlike a zero-length client answer to a 334 reply, a zero-
length initial response is sent as a single equals sign ("=").
If the client uses an initial-response argument to the AUTH
command with a mechanism that sends data in the initial
challenge, the server rejects the AUTH command with a 535
reply.


According to Internet Draft mentioned above (the only documentation for SASL LOGIN method), server sends initial challenge which is not empty:
Quote:

2.2. Server side of authentication protocol exchange

The server issues the string "User Name" in challenge, and receives a
client response.
This response is recorded as the authorization
identity. The server then issues the string "Password" in challenge,
and receives a client response.
Note: There is at least one widely deployed client which requires
that the challenge strings transmitted by the server be "Username:"
and "Password:" respectively. For this reason, server
implementations MAY send these challenge strings instead of those
listed above.

Quote:


BTW, the document you included a link to lists RFC 2554 in its references.

Yes, this is only informational reference.

As I wrote before, Internet Draft for SASL LOGIN is obsolete and you don't need to use LOGIN mechanism. You can just disable it in KMS and your problem disappears.

But you are right on one point: KMS should reject such AUTH command with 535 response.
  •  
apittsley

Messages: 3
Karma: 0
Send a private message to this user
Quote:

Yes, they can authenticate if they use LOGIN method correctly


Including the initial-response with the AUTH command is a correct use of the LOGIN method. There are a number of clients that do this (Exchange, Netscape). There are even some servers that, incorrectly, require the initial response to be on the command.

The initial response can not be included on the command when the server includes data with the initial challenge. The LOGIN method does not include data with the initial challenge. In fact, the client is suppose to "ignore" the contents of the challenge.

Quote:

But this is valid only for authentication methods that sends empty initial response (RFC 2554)


You have "challenge" and "response" mixed up.

Quote:

According to Internet Draft mentioned above (the only documentation for SASL LOGIN method), server sends initial challenge which is not empty


So, technically, its the AUTH command, as opposed to the LOGIN method, that KMS does not implement correctly.

Quote:

As I wrote before, Internet Draft for SASL LOGIN is obsolete and you don't need to use LOGIN mechanism. You can just disable it in KMS and your problem disappears.


Wrong. I tried. I need to use the LOGIN method.

Quote:

But you are right on one point: KMS should reject such AUTH command with 535 response.


I did not say that. And if I did say that I would be wrong.

The bottom line is- other SMTP servers can handle "AUTH LOGIN username". It should be a simple fix to KMS.

I see that you have hidden my post from other users. Why?

[Updated on: Sun, 05 March 2006 21:23]

  •  
Petr Dobry (Kerio)

Messages: 782
Karma: 61
Send a private message to this user
apittsley wrote on Sun, 05 March 2006 20:16

I see that you have hidden my post from other users. Why?



Your post is not hidden, this forum doesn't have an ability to "hide" posts. Just reload page, you have probably some old version in cache.

Petr Dobry
Product Development Manager | Kerio
Previous Topic: no support for group mailboxes?
Next Topic: Users guide for Entourage 2004
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Sun Nov 19 15:26:42 CET 2017

Total time taken to generate the page: 0.00580 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.