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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 8 Jun 2000 14:36:03 +1000

Larry,

I'm fascinated by

[ this next response would have to be done in plaintext]
S: a OK "Authentication succeeded using TLS/CRAM-MD5"

Can I substitute:

S: "Authentication failed. Try PLAIN"?

Ron.

-----Original Message-----
From: Lawrence Greenfield [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 13:05
To: [email-masked]
Cc: John Gardiner Myers
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

[...]
   Magnus Nystrom wrote:
   >  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.

   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.

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 22:51:18 -0700

> S: "Authentication failed. Try PLAIN"?

Sure.  You can even do this as soon as the client sends:

C: a AUTHENTICATE "TLS"

or even replace all the SASL mechanisms in the banner with just PLAIN. 
Or you can replace legitimate TLS records with TLS fatal alerts.

Protocol spoofers can do all sorts of interesting things if the
endpoints have a sufficiently lax security policy.

Which brings up an interesting point about the draft.  There's no point
having the mechanism support mutual authentication because the mechanism
doesn't support any security layers.  It's useless for the server to
prove its identity to the client since the moment the SASL negotiation
is over either side could be talking to anybody.

---

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

C: a AUTHENTICATE "TLS"