[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TURN and disconnected SMTP with dynamic IP addresses



>>First, I think it might help to have a way to tell a normal ETRN (which
>>should use the DNS) from a dynamic ETRN (which would normally use the
>>IP address that the client is presently on).  I was thinking of either
>>a new command (DTRN) or an optional parameter to ETRN:
>>
>>C: ETRN [192.168.15.2:8025] foobar.net
>
>Why?  This presents a security loophole.  The keys should be there to allow
>the site initiating the ETRN command to say that it wants extra verification
>when the connection is made.  As for a manner to determine permananent
>nodes versus transient nodes, isn't that the responsibility of the server
>side receiving the ETRN command?  You do not want to allow anyone to use
>the ETRN command to force mail to an arbitrary node.  If you have a given
>"switch" turn on on the server side, it will make a temporary entry into
>a local table that any STMP connections for foobar.net (using the above
>example) should use the IP address of the connection, 192.168.15.2.

What is the security hole?  The ETRN with IP would only be accepted
after authentication, and therefore it can be verified that the issue
is allowed to request mail for that domain.

(Specifying the IP address also makes it easy to specify a different
port, which might be needed, at least during a migration period, for
proxies and such).

I wouldn't want a host to be able to connect in an issue an ETRN for
domain x, and have the server ignore the DNS (assuming there was an
entry for x) and send the mail to the IP address of the connection.
That would be a security hole, unless the ETRN required authentication.
But you don't need authentication if the domain is in the DNS, so we're
back to needing a way to tell static from dynamic.



>Simpler, but possible to crack easily.  The key system is an optional
>system that allows for any ETRN submission to trivially get an extra
>level of certainty, mostly for dynamic IP address situations.

I like the double authentication mechanism, but it does mean more
round-trips and more complexity.

If we go with keys (random strings), I think having the server send
them in response to the ETRN/DTRN instead of having the client send
them in the ETRN/DTRN makes sense, because you'd want the client to
have some assurance that the server will use them, and because the
point is to assue the (original) server that it has indeed opened the
connection to the right host.

Actually, I'm now leaning toward a new command (DTRN), because that
makes it easier for the client and server to be sure about each other,
and it doesn't risk breaking the existing ETRN syntax.

The syntax would be something like:

DTRN domain; option=value

DTRN foobar.com; port=8025

So, the client would connect to the server, and look for AUTH and DTRN
in its EHLO response, then issue a DTRN command.  There is now no need
to specify the IP address, but there should be an optional port number.

We need to agree on the best way of closing the timing hole for the
second connection:

1.  Eliminate the second connection, by making DTRN turn the connection
(like TURN).

2.  Require (or suggest) that the second connection be authenticated.

3.  Require (or suggest) that the client send a random string (a key)
with the DTRN command, which would be echoed back during the second
connection.  We need to specify how the string is echoed back, since
the server is now the client.  A new command, probably.

4.  Require (or suggest) that the server send a random string (a key)
with the DTRN response, which would be echoed back during the second
connection.  We need to specify how the string is echoed back, since
the client is now the server.  Part of the EHLO response, probably.


(1) is probably the simplest, but is ugly, and is architecturaly
difficulty in some implementations.  It also means the client needs to
open a second connection itself, if it wants to send and receive mail
in parallel.

(2) is probably the safest, and as authentication mechanisms advance,
becomes more secure.  It also helps in other areas, such as
authenticated submission, and will probably be useful in ways that
won't be known until later.  It is the most complex, and requires the
most round-trips.

(3) is a compromise in security and complexity, but doesn't really
assure the (original) server that it reached the right host.

(4) is also a compromose in security and complexity.

I think (2) is probably best in the long run.


--
Randall Gellens       ||    Opinions are personal; facts are suspect;
randy@xxxxxxxxxxxx    ||    I speak for myself alone
--

Celebrate Hannibal Day this year.  Take an elephant to lunch.