Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

From: Magnus Nystrom <[email-masked]>
Date: Wed, 7 Jun 2000 19:25:57 +0200 (MET DST)

Dear Paul and John,

Thanks for your views. However, IMHO, TLS is not always suitable, for
several reasons. Among them are:

-(partially quoting from a posting by P. Fahn, Certicom, sent to
 another list:) Many network architectures today have
 "untrusted" middlemen (gateways, proxies, translators, formatters, and it
 is not unlikely that architectures like this will increase in numbers.

 The end users and content providers and application developers
 should be able to put in security on top of all the middlemen, at
 the application layer. And middlemen want the same thing to avoid the
 liability that comes with seeing all the plaintext. Since one will not
 always have simple two-party network topologies, simple transport-layer
 channel security will not always be enough.

-As mentioned in the draft, TLS is more complex and does not carry the
 concept of separate authentication and authorization identities.

Regards,
-- Magnus

On Tue, 6 Jun 2000, Paul Leach wrote:

> > -----Original Message-----
> > From: John Myers [mailto:[email-masked]]
> > Sent: Tuesday, June 06, 2000 5:03 PM
> > To: [email-masked]
> > Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
> > 
> > TLS does appear to have won the X.509 space and is gaining
> > implementation momentum.  I think this draft is approaching the
> > wrong problem. 
> 
> I concur completely.
> 
> Paul

---

From: [email-masked] (John Myers)
Date: Wed, 07 Jun 2000 18:26:05 -0700

Magnus Nystrom wrote:
>  the application layer.

TLS and SASL are both session layer protocols.  The name "Transport
Layer Security" is a misnomer, TLS is not part of TCP, it is a layer
above TCP.  Anywhere you can add a command to a protocol to do a SASL
negotiation you can also add a command to do a TLS negotiation.

>  And middlemen want the same thing to avoid the
>  liability that comes with seeing all the plaintext.

Since proposed SASL mechanism doesn't support any security layers, when
it is used the middlemen will always see the plaintext.

>  concept of separate authentication and authorization identities.

The concept of separate authentication and authorization identities is
handled through the use of the EXTERNAL SASL mechanism once the TLS
negotiation is complete.  As I have mentioned before, TLS complexity is
small compared to the complexity of key and certificate management, as
evidenced by the number of applications implementing TLS but not
implementing client certs.

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 7 Jun 2000 23:04:30 -0400 (EDT)

[...]

To be silly, why not do just this?  A "TLS" SASL mechanism could
easily be made.  For example (using ACAP as the protocol to avoid
base64 encoding):

C: a AUTHENTICATE "TLS"
S: "ok, start TLS negotiation"
C: {xxx+}
C: tls negotiation
S: + {xxx}
S: more tls negotiation
C: {xxx+}
C: tls negotiation
...
S: + "TLS done. AUTH=PLAIN AUTH=CRAM-MD5"
[ tls security layer takes effect here ]
C: "CRAM-MD5"
S: + "<[email-masked]>"
C: "response"
[ this next response would have to be done in plaintext]
S: a OK "Authentication succeeded using TLS/CRAM-MD5"
[ tls security layer resumed ]

This seems more useful than this proposed mechanism.  It allows TLS to
be negotiated in any protocol that has a SASL profile.

I shudder to add a third option to existing protocols (IMAP, POP) by
suggesting this (and I think that sinks this idea) but hey.  It does
mean that existing protocols need not define a STARTTLS command.

Larry

---

From: [email-masked] (John Myers)
Date: Wed, 07 Jun 2000 18:26:05 -0700

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 7 Jun 2000 23:04:30 -0400 (EDT)

[...]

C: a AUTHENTICATE "TLS"

Larry