Message-Id: <6.2.1.2.2.20050612102929.04097eb0@mail.jefsey.com>
Date: Sun, 12 Jun 2005 10:33:48 +0200
To: John C Klensin <john-ietf@jck.com>,
	Christian Huitema <huitema@windows.microsoft.com>,
	Brian E Carpenter <brc@zurich.ibm.com>,
	Keith Moore <moore@cs.utk.edu>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <6C484FC792B2E47F82054CF9@scan.jck.com>
References: <DAC3FCB50E31C54987CD10797DA511BA0F236015@WIN-MSG-10.
	wingroup.windeploy.ntdev.microsoft.com>
	<6C484FC792B2E47F82054CF9@scan.jck.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org, iesg@ietf.org, Dave Crocker <dcrocker@bbiw.net>
Subject: Re: Client and server authentication for email (was: RE: Last
 Call: 'Email Submission Between Independent Networks' to BCP)
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 16:56 11/06/2005, John C Klensin wrote:
>         (2) If the key issue is "be sure you are talking to the
>         right server", then one could still use a
>         challenge-response mechanism as long as the server were
>         properly verified to the client.  Presumably that could
>         be accomplished by client possession and verification of
>         a server key or by an extra secret and handshake. That
>         would presumably be "good enough" unless we also have a
>         significant concern about sessions being hijacked once
>         they have been properly initiated. I don't know the
>         degree to which that is a practical concern (remember
>         that SMTP sessions, especially pipelined ones, are
>         typically pretty short and that, e.g., IMAP has
>         provisions for in-session reverification although I
>         believe they are still not intensively used).
>         Conversely, if the server identity is not verified, or
>         is verified only by the luser's receiving an
>         incomprehensible warning message and clicking "accept"
>         every time, then even encryption wouldn't seem to help
>         much.

Yes. This is why I rise the multimodal general issue (can be check-back 
procedure, parallel exchanges, multichannels, multitechnology, etc.). This 
also goes with a generalised usage of IPv6 (identification of a permanent 
address - I do not think the IPSEC is of interest here as one never knows 
about the real end to end path?).
jfc



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf