Subject: TLS/SASL

From: John Gardiner Myers <[email-masked]>
Date: Thu, 20 Mar 1997 15:41:12 -0500 (EST)

> In talking to the SASL author about this, he has no strong feeling
whether
> I should add TLS to SASL or just come up with a set of non-SASL
proposals
> for SMTP/IMAP/POP over TLS.

I think a better way to charactarize my opinion is that I am not
dead-set on using SASL to the exclusion of considering other
alternatives.  There are numerous possible approaches, each with its
advantages and disadvantages.  These need to be discussed.

> That would make it very difficult for people to use out-of-the-box
> SSL kits.

We should not put the cart before the horse.  If, as I believe,
existing out-of-the-box SSL kits do not adequately solve the problem,
we should not be driven by what out-of-the-box SSL kits can do.  We
should be driven by what solves the problem.

A summary of the possible approaches are:

1) TLS on separate port.  

Advantages:

1a) can use SSL kits "out of the box"

Disadvantages:

1b) Consumes an additional port per protocol.

1c) Does not include a mechanism to communicate an authorization
identity (userid) separate from user credentials.  (This is necessary
to handle cases such as where an admin or proxy is acting on behalf of
another user.)

1d) Does not necessarily authenticate the user, leading to different
parts of the authentication being handled at different layers.
(e.g. server authentication at SSL layer, user authentication using
plaintext passwords at the protocol layer.)

2) Add a command to "turn on" TLS

Advantages:

2a) Less bit twiddling than SSL under SASL.

2b) Doesn't consume additional port

Disadvantages:

2c) Same as 1c (communicate userid)

2d) Same as 1d (authentication spread over multiple layers)

2e) If no acceptable common TLS mechanism can be negotiated,
attempting to use a non-TLS authentication mechanism requires closing
and re-opening the connection.

2f) Differences in the framing for TLS and SASL requires a slightly
more complex I/O routines for applications which use non-blocking or
asynchronous I/O.

3) TLS under SASL

Advantages:

3a) More flexible choice of authentication/security mechanisms.
(e.g. Don't get tied to RSA)

3b) Same as 2b (doesn't consume additional port)

3c) Converse of 1c (can communicate userid)

3d) Converse of 1d (authentication is a single layer, useful to the
application)

Disadvantages:

3e) More bit-twiddling, especially for folks who only care about TLS.

3f) Overlap/mismatch between TLS and SASL.

I'm sure others can add to these.  The key point I want to get across
to those with a SSL/TLS background is that TLS as a framework and as
an existing implementation lacks some features/capabilities which are
very important to the applications/mail community.  I don't have
religious convictions on how these capabilities are provided, but I
don't see current straight-SSL approaches moving towards providing
those capabilities.

-- 
_.John Gardiner Myers	Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up