Subject: Interactivity in SASL mechanisms

From: Laurence Lundblade <[email-masked]>
Date: Wed, 08 Sep 1999 10:46:13 -0700

Looking at a couple of the newer SASL mechanisms such as DIGEST and 
SecureID I see they presume the possibility of some interaction with the 
user during the SASL negotiation. I believe this can't be avoided in some 
cases, but it is undesirable as for example:

- mail checking and sending are often unattended
- interaction increases connect time which:
     - can cost if you pay by the minute (e.g. wireless data call)
     - can add load to the server (processes hang around)
- mail checks often connect to multiple mail servers. It is better
   to get all the credentials up front before all the mail checks
   start because one often starts a mail check and then goes
   for a cup of coffee or such
- mail checking and sending are often background operations
   and popping up dialogues for authentication can be confusing

One thing I've done already with SMTP AUTH is to remember what the server 
said last time. This may work with things like realms but I haven't tried 
to implement it yet.

So it seems that eliminating interactively would be a good thing for SASL 
mechanisms.

LL

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 9 Sep 1999 05:28:38 +0000 ( )

On Wed, 8 Sep 1999, Laurence Lundblade wrote:

> ...
> So it seems that eliminating interactivity would be a good thing for
> SASL mechanisms.

In any non-trivial authentication mechanism the client has to come up with
some credentials; and other parts of the authentication exchange may need
some user-provided info.  Whether a particular client implementation
provides for both interactive and unattended operation is a client
implementation issue.  A client supports interactivity by being
prepared to do popup dialog boxes or other UI whenever it needs info it
doesn't have.  A client supports unattended operation by providing
locations to find the needed info, by having a scripting language, by
requesting needed info up front and using it for the life of a session or
saving it as a profile, etc.

Whether a particular deployment can operate in an unattended fashion, or
without bothersome UI, is mostly a deployment issue.  It bugs me that most
client/server discussions these days assume that the wide-open Internet
scenario, myriad clients contacting myriad servers with which they have no
prior relationship (ie, the surfing-the-web scenario), is the only
scenario of interest; when in fact for many if not most deployed
applications, clients talk to the servers they're configured to talk to,
and with which they share a security realm, and things are much easier.
So, if you don't want an annoying dialog box to pop up asking which realm
to choose, configure your client with which realm to use with which
server, and that's that.

So if you're saying that well-designed clients need to support
interactivity when needed and unattended operation when needed, I agree.
If you're suggesting that mechanisms need to change to make this possible,
I don't.

 - RL "Bob"

---

From: [email-masked] (Rob Weltman)
Date: Wed, 08 Sep 1999 22:59:32 -0700

Both the C SASL client API of the Cyrus package - ftp://ftp.andrew.cmu.edu/pub/cyrus-mail - and the proposed Java SASL client API of http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-02.txt include callback interfaces for acquiring additional credentials during negotiation. It's up to the client to implement the callbacks. As Bob writes, you can configure your callbacks with predefined credentials if you're in a known and shared security realm, or have them present an appropriate UI to obtain them from the user in the more general case.

Rob

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 09 Sep 1999 08:48:52 -0700

Probably obvious, but my main concern was interactivity while connected to 
the server, not interactivity in general.

My main thought was that SASL mechanisms should be designed to support 
unattended operation when possible.

Another related and interesting side-effect of mechanisms like DIGEST is 
that they don't reveal the credentials to the server. This allows clients 
to rummage through their authentication wallet for credentials for a given 
realm and safely try it with the server without even prompting the user (if 
appropriate). I think this makes mechanisms like DIGEST useful even inside 
a TLS secured connection to a server where you're not worried about eaves 
droppers but are worried about revealing credentials to an imposter server.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 08 Sep 1999 10:46:13 -0700

LL

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 9 Sep 1999 05:28:38 +0000 ( )

- RL "Bob"

---

From: [email-masked] (Rob Weltman)
Date: Wed, 08 Sep 1999 22:59:32 -0700

Rob

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 09 Sep 1999 08:48:52 -0700

LL