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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf