--On Tuesday, 26 June, 2001 13:04 +0530 Koti
<theearth1947(_at_)yahoo(_dot_)com> wrote:
Hi,
For example: I am using Eudora as an email client & gave pop
server name for getting mails, smtp server name for sending
mails. For example pop server
is pop3.mail.yahoo.com, smtp.mail.yahoo.com. If set an option
like "use authentication mechanisam while logging." assume
that client(eudora) & server (smtp.yahoo)
supports that authentication mechanisam.
It appears that some tutorial is needed, and that you are not
the only one confused. Let me try...
First of all, I have no idea whether Yahoo (or whatever server
you are using) supports CRAM-MD5. There are several possible
"authentication mechanisms"; you would need to clarify whether
what they support is usuable by your client.
As Paul Smith's note more or less suggests, the term "shared
secret" is a generalization. I.e., "passwords" are a special
case of shared secrets. For technical and security reasons
(consult any good reference on hash-based authentication or
signature systems if you are interested), it is desirable that
the "secrets" used in CRAM-MD5 and methods similar to it be much
longer than the traditional typical "password" (it is also
desirable that passwords be longer and more complex than the
typical password, which is not an independent observation).
The answer to how you and the server get and retain the shared
secret is the same as it would be with passwords -- you need to
set the value for the server in a secure way, or transmit it out
of band. And then you need to supply it, or a key to unlock a
saved copy of it, from the client to the server at appropriate
times. Storing it locally in cleartext is not generally
considered to be a good practice.
More generally, if one does authentication by transmitting a
password (or "shared secret") across the network in cleartext,
one is vunerable to the possibility of someone compromising and
monitoring the network and thereby obtaining the secret, which
can later by used to compromise your account. In order to
reduce that risk at least one of the three conditions implied by
that statement must be changed, i.e.:
(i) One avoids tranmitting the secret at all. This
turns into an exercise of proving to the server that you
know a particular secret without disclosing the secret
or passing it across the network. CRAM-MD5 is a member
of this class of techniques.
(ii) One encrypts the transmission of the secret, either
directly or by encrypting the entire data stream in
which the secret (or password) is embedded. The
approaches based on using SSL or TLS to hide
authentication transactions fall into this class.
(iii) One eliminates the use of a shared secret at all,
relying instead on, e.g., a public key approach.
There are no perfect solutions; each of the above has its
advantages and disadvantages. And, in all cases, any method not
supported by both your client software and the server software
is not going to be available to you.
So...
1. then How can server & client maintain shared secret?
More or less the same way they do passwords. From the client
side, ideally the way you ideally maintain passwords, i.e., by
not writing them down or keeping them on your computer. On the
server side, there is an additional complication, which is that
traditional passwords can be stored in a one-way encrypted
(hashed) form, while techniques similar to CRAM-MD5 require that
the server be able to recover the secret (or an algorithmic
variant on it) in order to make the required calculations. How
much additional protection (or risk) this difference implies is
debated, but it essentially trades off reduced risk from
interception of the password on the network for increased risk
of passwords (secrets) being compromised if the server is
compromised.
2. Is it some constat string understood by client & server ?
typically
3. if somebody implements new email client which supports those
auth mechanisams, How it will know the shared secret? how
it will connect to that server?
In the same fashion that a client and server are instructed
about a password. I.e., either the secret is generated by, and
stored on, the server or as a part of its operational setup and
then transmitted, preferably in some secure way, to the user; or
the user picks and specifies the secret and transmits it to the
server (again, preferably in some secure way).
Hope that helps.
john