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

---

From: Mike Macgirvin <[email-masked]>
Date: Thu, 20 Mar 1997 14:58:45 -0800 (PST)

> 1b) Consumes an additional port per protocol.

	No argument. I would point out that there are a huge number of orphaned
braindumps populating the reserved port range. We really aren't anywhere close
to running out if somebody would just do a gc.

> to handle cases such as where an admin or proxy is acting on behalf of

	This is not built into the application protocol anyway. In fact, I'd
say that the opposite is true. Under SSLv3 client auth, there are two possible
identities depending on how the server is configured to handle client SSL
credentials. It may accept or reject either the SSL credentials and/or the
LOGIN (or other AUTHENTICATE) credentials. 
	...I've actually been working on the framework for a proxy
authentication extension to IMAP because the protocol itself does not define a
mechanism for this {outside of ACL control}, and customers require it. (If
anybody is interested, please reply. I'll publish when a few other folks have
reviewed it).

> plaintext passwords at the protocol layer.)
  
	Again, the server may be configured in such a way that enforces user
authentication in the SSL layer (i.e. issuing a PREAUTH in the IMAP case), or
on failure 
	1. rejecting the client
	2. allow a normal login

	So you have a choice of certificates or passwords or both. This is all
a matter of site policy. I suspect many sites will opt for both in the near
future while certificate infrastructures are under construction. They gain the
immediate advantage of un-sniffable communications and a much greater
immunity from session hijacking; and they can still use their existing password
based authentication databases. Once they have a certificate infrastructure,
(should they choose to) they can turn off the password login.

	Yes, there could potentially be a layer mismatch, or not... 

> should be driven by what solves the problem.

	Exactly. 

Jack De Winter:

> I guess from my viewpoint, I would prefer to see everything 'under
> the auspices of SASL'... face it, having one interface that takes
> care of the other authentications and encryptions is a lot easier to
> code to and explain than having this command for this authentication
> and that command for that encryption.

As I tried to point out in an earlier message, I too would prefer to see this.
The concept is elegant. But as I also pointed out, SASL does not provide for
the full spectrum of authentication and encryption possibilities because it is
at its core an authentication mechanism; and at a minimum would need to be
extended to cover a separate encryption function to allow SSL to map to it
effectively. To really be viable it also would need to be able to implement and
make known site policy on both a per-server and per-user basis. To solve this
introduces the same problem John brought up earlier in another context, that of
layering. We would conceivable have an application layer trying to deal with
system configuration and site policy issues which live elsewhere. 

Also due to export restrictions, SASL (or at least the encryption algorithms it
supports) generally need to be embedded in the application if the application
will be exported and contains any munitions - shared libs are a no-no. So the
entire concept of plugin authentication is thrown to the wind anyway. This
isn't an indictment of SASL so much as one of government policy, but I mention
it because it is yet another factor in extensibility. 

- I'm also not trying to slam SASL. I'm just pointing out my observations over
the last year or two in trying to make use of it effectively. I've currently
shelved the effort of shoehorning SSL into it; but still willing to do so if
we can nail down the couple of issues which make it sticky.

jgm:

> I'm not trying to bash SSL/TLS; it's got some great engineering in it.
> I just want to point out where some of the assumptions/dogma of
> current SSL practice are flawed and hopefully engineer the best
> solution.

- Came in after I had composed the last paragraph - honest...

> I'm sorry, but this last bit of reasoning is flawed.  A separate port
> does not solve this problem.  An active attacker could similarly cause
> the attempt to connect to the SSL port to fail with "connection
> refused", causing a client to fall back on lesser forms of
> authentication on a non-SSL port.

> No matter how you slice it, both the server and client are responsible
> for having and imposing some policy on the minimum acceptable security
> it is willing to use.

Not if there is no server on that port. It is entirely reasonable and
completely justified for site policy to dictate that it is imaps or nada. The
client has no say in the matter.

> For protocols such as POP/IMAP, client authentication is critical.
> Effort spent protecting the stream without addressing the client
> authentication problem is misdirected.  You end up with the illusion
> of solving the "security" problem without actually having done so.

I covered this earlier. Client authentication may be enforced by the site
mandating SSLv3 client auth or nada. When client and server start exchanging
IMAP protocol, they have already both established the other one's identity
beyond any reasonable doubt and protected the stream. IMAP only needs to be
involved in this effort to the extent of displaying a PREAUTH banner and
putting its command loop in the appropriate authenticated state. 

Apologies for the long-winded reply...

---

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

Mike Macgirvin <[email-masked]> writes:
>         This is not built into the application protocol anyway.

I'm not sure what you mean here.  Most protocols have an
"unauthenticated" and an "authenticated" state.  When they get to the
"authenticated" state, they have a concept of a userid which is a
key used for determining what kind of access they give to the client.

With plaintext passwords, the credentials are replayable, so having
different authorization and authentication identities was not an
issue.  With non-replayable credentials, the concept of having an
authentication identity separate from the identity in the credentials
still fits in with the "something happens and then you're
authenticated" model.

> In fact, I'd say that the opposite is true. Under SSLv3 client auth,
> there are two possible identities depending on how the server is
> configured to handle client SSL credentials. It may accept or reject
> either the SSL credentials and/or the LOGIN (or other AUTHENTICATE)
> credentials.

Here you're not talking about separate authentication and
authorization identities, you're talking about having two different
authentication credentials at two different layers.  This is a really
messy way of doing things.

> authentication extension to IMAP because the protocol itself does
> not define a mechanism for this {outside of ACL control}, and
> customers require it.

I'm surprised.  CMU was doing proxy authentication in IMAP years ago,
using the mechanisms defined in 1730 and 1731.  The SASL framework,
along with a SASL mechanism that supports a separate authorization
identity and an implementation which knows how to apply a policy on
what authentication idenity can use what authorization identiy,
supports this.

>         So you have a choice of certificates or passwords or both.

So in the absense of certificates, you have to do an authentication at
a different layer.  Extremely messy.

> But as I also pointed out, SASL does not provide for
> effectively.

In the case of POP and IMAP, encryption without authentication is
practically useless.  (In the case of SMTP, lack of authentication may
be useful, but in a SASL model, this can be handled by authenticating
as the anonymous identity.)

A mapping of SSL under SASL will likely require some post-traditional-SSL
negotiation of an authorization identity and possibly a password (to
handle the encrypted-plaintext-password case of classic-SSL.)  I
personally think it would be cleaner if the first or both of these
negotiations were in SSL proper as opposed to being in a
SSL-under-SASL spec.  This would have the added advantage of being
cleaner in a SSL-on-separate-port advantage as well.

> To really be viable it also would need to be able to implement and
> make known site policy on both a per-server and per-user basis. To
> solve this introduces the same problem John brought up earlier in
> another context, that of layering. We would conceivable have an
> application layer trying to deal with system configuration and site
> policy issues which live elsewhere.

I'm missing the step explaining how SSL-on-separate-port more easily
facilitates dealing with system configuration and site policy issues
elsewhere.  I know of the argument where one can shut off access to
the non-SSL port on a system or firewall basis, but that only lets one
set a policy with the same minimums as the SSL protocol itself.  Given
SSL effectively permits plaintext passwords encrypted with 40-bit
keys, this isn't compelling.

> Also due to export restrictions, SASL (or at least the encryption
> algorithms it supports) generally need to be embedded in the
> application if the application will be exported and contains any
> munitions - shared libs are a no-no.

Similar arguments apply to SSL.  SSL libs would similarly need to be
embedded in the application.  Wherever the policy comes from, it needs
to be known by some part of the application.

> client has no say in the matter.

If the active attacker fakes a connection refused on imaps and
poses as a plain-imap service, it can fool the client into doing weak
authentication.  It does not matter whether or not the real server
supports the plain-imap service.

Removing support for the plain-imap service is exactly equivalent to
the server imposing a minimum acceptable security policy equivalent to
the minimum security of SSL.  It is only interesting when the minimum
security policy of the site matches the minimum security provied by SSL.

> mandating SSLv3 client auth or nada.

This is only interesting when SSLv3 client certificates is the only
authentication mechanism to be supported.  And it does not address the
proxying issue.

---

From: Mike Macgirvin <[email-masked]>
Date: Thu, 20 Mar 1997 14:58:45 -0800 (PST)

Exactly.

---

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

Date: Thu, 20 Mar 1997 20:29:07 -0500 (EST)
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: Re: TLS/SASL
Sender: [email-masked]

Date: Thu, 20 Mar 1997 14:58:45 -0800 (PST)
From: Mike Macgirvin <[email-masked]>
Reply-To: Mike Macgirvin <[email-masked]>
Subject: Re: TLS/SASL
To: John Gardiner Myers <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

  

	Exactly. 

Date: Thu, 20 Mar 1997 17:29:28 -0500 (EST)
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: Session hijacking
Sender: [email-masked]

Mike Macgirvin writes:
> The secondary issue, and the reason Netscape isn't pushing real hard
> on this right now is the problem of session hijacking. It would be the
> responsibility of the _client_ to refuse to fall back on lesser forms of
> authentication if a server which was previously known to provide an
> SSL mechanism all of a sudden doesn't. (The assumption is the
> session could be hijacked and a phony CAPABILITY response returned,
> minus AUTH=SSL - in the case of IMAP). This puts the burden on the
> client to know in advance the supported auth mechanisms. 

> It is the prevailing opinion here that this makes the ability to go
> from plaintext to "secure" fundamentally flawed.  We are therefore assuming
> a reserved port. 

> Another lesser concern is that SSL is primarily a stream protection
> mechanism, where client authentication is secondary. This doesn't
> quite fit the SASL model which general assumes the opposite. SASL is
> an authentication mechansim, and stream protection is secondary.
> It's also optional, under Kerberos anyway.

Solving authentication without stream protection is a relatively weak
quality of security, but it is unfortunately a quality made necessary
by export controls.  It is roughly the same level of quality as doing
stream "protection" with 40-bit crypto.

Date: Thu, 20 Mar 1997 16:16:11 -0500
To: John Gardiner Myers <[email-masked]>, [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Re: TLS/SASL
Sender: [email-masked]

Where this breaks down is applicability.  I have heard some verifiable
comments from a couple of sources that worry about a SASL-SSL downgrading
to a SASL-<x> without warning the user.  While I think this is a client
and server problem (both should have restrictions to limit the concept
of a secure connection and should notify the user if possible), it is still
a problem.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

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

whether
proposals

1) TLS on separate port.  

Advantages:

Disadvantages:

Advantages:

Disadvantages:

3) TLS under SASL

Advantages:

Disadvantages:

Date: Thu, 20 Mar 1997 09:27:15 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: anyone else on this list?
To: [email-masked]
Sender: [email-masked]

SSL has a number of other problems.  I doubt it permits both
authentication and authorization as the SASL kerberos mechanism does.
Specificly, it's useful to have an authentication credential that's
capable of authorizing access to multiple accounts.  This is especially
important for proxy operations.

In addition, SSL is primarily used in an RSA framework.  This requires
patent blood money, and thanks to RSA's rather annoying licensing rules
it's nearly impossible to get a "site license" for RSA.  By the IETF's
rules, that would tend to rule out standardization of any RSA-only
mechanism.

SSL is currently a session/presentation level mechanism, while SASL is an
application level mechanism.  Trying to fit these two different paradigms
together isn't easy, either.

It's probably worth trying to fit SSL under SASL to get the nice
authentication/encryption plug-in model that SASL provides and to avoid
SSL's excessive use of reserved ports in the case of IMAP, POP and SMTP.
It's probably a toss up whether to try to shoehorn SSL's session layer on
top of SASL's or to make an exception to SASL and replace its session
layer with SSL's session layer.  Pick one and see how it implements.

Date: Wed, 19 Mar 1997 21:01:30 -0500
To: [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Re: anyone else on this list?
Sender: [email-masked]

Sent this to Paul personally, instead of Paul and the list...

regards,
Jack

>>From [email-masked] Wed Mar 19 20:14:31 1997
>Date: Wed, 19 Mar 1997 17:25:27 -0800
>To: "Jack De Winter" <[email-masked]>
>From: "Paul E. Hoffman" <[email-masked]>
>Subject: Re: anyone else on this list?
>
>Jack, I noticed that you sent this to me personally. Given that someone
>from Netscape just said pretty much the opposite as you, I think you should
>send this to the list as well.
>
>--Paul Hoffman
>
>>At 03:22 PM 3/19/97 -0800, you wrote:
>>>At 8:41 PM -0800 3/18/97, Jack De Winter wrote:
>>>>how many people are on this list?
>>>
>>>Believe it or not, 46. *Someone* out there must have an opinion about SSL
>>>under SASL...
>>
>>okay... my opinion is that ANY authentication/encryption thing should be
>>done under SASL.  SASL is a great portable framework for adapting a whole
>>slew of interfaces to one interfacing method.
>>
>>That being said, is there anything in the specs for SSL that would forbid
>>it to be "switched on" when negotiated, as opposed to from the beginning of
>>the session?  Would this be against what it is set up for with HTTP?  Does
>>it need anything outside of the given protocol implementing SASL to function
>>properly?
>>
>>regards,
>>Jack
>>-------------------------------------------------
>>Jack De Winter - Wildbear Consulting, Inc.
>>(519) 576-3873		http://www.wildbear.on.ca/
>>
>>Author of SLMail for 95 & NT (http://www.seattlelab.com/)
>
>
>
>
>
>
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

Date: Wed, 19 Mar 1997 16:32:55 -0800 (PST)
From: Mike Macgirvin <[email-masked]>
Reply-To: Mike Macgirvin <[email-masked]>
Subject: Re: anyone else on this list?
To: "Paul E. Hoffman" <[email-masked]>
cc: Jack De Winter <[email-masked]>, [email-masked]
Sender: [email-masked]

> Believe it or not, 46. *Someone* out there must have an opinion about SSL
> under SASL...

Yes, actually, but too busy to respond in depth currently.

I've discussed this offline with John Meyers and Larry Osterman (Microsoft)
several months back. The main protocol issue is the one pointed out in your
earlier message, i.e. framing and the size field. 

The secondary issue, and the reason Netscape isn't pushing real hard on this
right now is the problem of session hijacking. It would be the responsibility
of the _client_ to refuse to fall back on lesser forms of authentication if a
server which was previously known to provide an SSL mechanism all of a sudden
doesn't. (The assumption is the session could be hijacked and a phony
CAPABILITY response returned, minus AUTH=SSL - in the case of IMAP). This puts
the burden on the client to know in advance the supported auth mechanisms. 

It is the prevailing opinion here that this makes the ability to go from
plaintext to "secure" fundamentally flawed.  We are therefore assuming a
reserved port. This actually works quite well in the IMAP model because with
SSLv3 client authentication, we can issue a PREAUTH banner if the client
certificate maps to one we will accept. Otherwise, a normal password login may
be done over the secured channel. 

Another lesser concern is that SSL is primarily a stream protection mechanism,
where client authentication is secondary. This doesn't quite fit the SASL model
which general assumes the opposite. SASL is an authentication mechansim, and
stream protection is secondary. It's also optional, under Kerberos anyway.

SASL also - while providing a list of authentication mechanisms, doesn't allow
one to specify the preferred or perhaps enforced order of them. It also doesn't
map easily onto directory services, where credentials could be mapped to
specific types of authentication. For instance, under LDAP, the "password"
field of the typical inetOrg person typically also defines and includes the
encryption algorithm. For us to announce (again assuming IMAP) a list of
authentication types before knowing the identity of the principal, we may be
providing bogus information because only one type might ulitmately succeed;
that or those which the directory service recognizes for this particular
individual.

In other words, despite SASL's elegance in theory, and with a known subset of
auth services like Kerberos and perhaps GSSAPI and S/KEY, in practice, and once
you step outside those boundaries, it can be a bloody pain in the arse.

/* ==================== PERSONAL OPINION of ======================== */
/* Mike "The MAX" Macgirvin      mailto:[email-masked]             */
/* Postmaster General            http://www.netscape.com/people/max/ */
/* Messaging Server Development  Netscape Communications Corporation */
/* ================================================================= */

Date: Wed, 19 Mar 1997 15:22:20 -0800
To: "Jack De Winter" <[email-masked]>, [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: anyone else on this list?
Sender: [email-masked]

At 8:41 PM -0800 3/18/97, Jack De Winter wrote:
>how many people are on this list?

Believe it or not, 46. *Someone* out there must have an opinion about SSL
under SASL...

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Mark Miller <[email-masked]>
Reply-To: [email-masked]
To: Jack De Winter <[email-masked]>
cc: [email-masked]
Subject: Re: anyone else on this list?
Date: Wed, 19 Mar 1997 13:41:27 -0700 (MST)
Sender: [email-masked]

++count;

Mark.
On Tue, 18 Mar 1997 23:41:32 -0500 Jack De Winter <[email-masked]> 
wrote:

> how many people are on this list?
> 
> regards,
> Jack
> -------------------------------------------------
> Jack De Winter - Wildbear Consulting, Inc.
> (519) 576-3873		http://www.wildbear.on.ca/
> 
> Author of SLMail for 95 & NT (http://www.seattlelab.com/)

----------------------
Mark Miller
[email-masked]

Date: Tue, 18 Mar 1997 23:41:32 -0500
To: [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: anyone else on this list?
Sender: [email-masked]

how many people are on this list?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

Date: Tue, 18 Mar 1997 17:52:51 -0800
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: SSL under SASL
Sender: [email-masked]

Hi, again. I'm going to be writing drafts on how to do SMTP, IMAP, and POP
over SSL. I sent the following message to the ietf-tls list earlier this
week:

=========================
Greetings. I'm going to be writing drafts on how to run the three primary
email protocols (SMTP, IMAP, and POP) over TLS. There is already an active
draft out for these three protocols that acts as a "front end" to
authentication and security protocols. This over-protocol, SASL, doesn't
yet have a mechanism for TLS built into it: it now covers Kerberos 4,
GSSAPI, and S/Key.

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'd like some TLS-savvy folks to take a look at
the SASL draft and discuss the merits of calling TLS from SASL on the SASL
mailing list. I don't think it is necessary to Cc this list on the
discussion; I'll summarize the results later.

To find the current SASL drafts and info on how to subscribe to the SASL
mailing list, please see <http://www.imc.org/ietf-sasl/>.

Thanks in advance.
=========================

Unfortunately, only two people signed up to this (ief-sasl) list in
response to this. I'd like to hear people's thoughts here before I decide
whether to use SASL as the mechanism for SSL or whether to do an orthogonal
approach.

My biggest concern is the last paragraph of section 3. Part of it says
"Each buffer is transferred over the connection as a stream of octets
prepended with a four octet field in network byte order that represents the
length of the following buffer." If I'm not mistaken, this means that if
someone has implemented SSL, they must *also* add this count to each
buffer. That would make it very difficult for people to use out-of-the-box
SSL kits.

Comments?

--Paul E. Hoffman, Director
--Internet Mail Consortium