On Thu, 2004-07-01 at 07:10, Tony Finch wrote:
On Thu, 1 Jul 2004, Dave Crocker wrote:
Since Doug raised the issue, but separate from Andrew's question (and,
hence, the different subject line), the discussion of multiple host
authentication techniques produced a basic hole, with the possibility
that the authenticated identity could be different from the one
asserted in HELO. This is a dangerous hole, indeed.
The resolution is to use whatever domain is associated with the
authentication, rather than the one in the HELO.
I think I've already noted that SASL is usually used to authenticate a
user name not a host name, so the potential for confusion and inadvertent
spelunking is high.
This is covered in Dave's CSV draft, but as SASL is useful only within a
Closed system, perhaps a statement that both authentication and
authorization are presumed of a holder of secret information, used to
authenticate, where the relevant accreditation namespace is dependent
upon the Open method used. This would presume a Closed method would not
require accreditation.
This is aside from the problems that it doesn't fulfill the requirement
for avoiding prior arrangement stated in section 2.2 of the CSV doc, and
that its organizational complexity is the square of the number of MTAs.
The cost of TLS with trusted third parties is linear in both dollars and
complexity. DNS-based authentication is free and scales linearly, and is
extremely efficient in conjunction with CSA.
(The above reasoning is why I think the CSV spec should not be over-
complicated with consideration of multiple authentication methods because
the alternatives are all substantially worse than using the DNS.)
When the client states its identity multiple times should all of the
statements agree?
No. Not as currently defined by RFC3207.
REF3207 states:
: 4.2 Result of the STARTTLS Command
:
: Upon completion of the TLS handshake, the SMTP protocol is reset to
: the initial state (the state in SMTP after a server issues a 220
: service ready greeting). The server MUST discard any knowledge
: obtained from the client, such as the argument to the EHLO command,
: which was not obtained from the TLS negotiation itself. The client
: MUST discard any knowledge obtained from the server, such as the list
: of SMTP service extensions, which was not obtained from the TLS
: negotiation itself. The client SHOULD send an EHLO command as the
: first command after a successful TLS negotiation.
It should be assumed the HELO/EHLO domain may not be indicative of the
HELO/EHLO once privacy is established. This may mean that if StartTLS
is in progress, not to act upon the HELO until the TLS process
completes. There are never two valid HELO domains of which to choose.
The specification clearly states to discard previous results.
Caveat:
If it is felt StartTLS is not useful in this role of authenticating and
authorizing with a public server, then requiring the initial HELO/EHLO
domain to be valid (or perhaps understood as a site defined pass
phrase), then exposures would be reduced as there would be no need to
wait for TLS. The TLS session HELO/EHLO domain would be unimportant if
the client was validated by a Certificate Authority and thereby
recognized. If not, then the TLS session HELO domain should match.
Should the server reject the client if they do not?
No. Discard the first as currently defined.
These questions almost go away if TLS and SASL authentication are no
longer considered relevant to CSV.
SASL is a closed mechanism, with the exception made by RFC2245, stronger
than CSV, except for the exception made by RFC2245.
TLS _may_ become an open mechanism, albeit expensive to use.
However there should probably be some comment in the CSA specification
about what the server does when the client says EHLO more than once.
I feel this is not needed as it is covered in RFC3207. I would also
like to limit the topic of TLS to a single document... Dave's of course.
: )
-Doug