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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 8 Jun 2000 11:54:47 +1000

I must have blinked.

I thought the statement at issue was that TLS is a good poit-to-point
solution but that it can't be used where middle-men are involved (DMZs, for
example).

In particular, SASL/EXTERNAL cannot be used.

I don't believe TLS is a session layer protocol, either. Its purpose and
implementation are as a network layer look-alike. Wherever TCP is found, TLS
may be shimmed in. So, it provides neither transport nor session services.

I also can't understand references to SASL services and then proposing to
use TLS without client certificates. Even if SASL/EXTERNAL could be used, it
would be useless without client certificates.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 11:26
To: [email-masked]
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.

>  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.

> -As mentioned in the draft, TLS is more complex and does not carry the
>  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: [email-masked] (John Myers)
Date: Wed, 07 Jun 2000 19:23:02 -0700

> solution but that it can't be used where middle-men are involved (DMZs, for

I am indeed taking issue with this statement.  Anywhere you have a SASL
protocol definition conforming to RFC 2222 section 4, I can construct an
extension to do a TLS negotiation.

> In particular, SASL/EXTERNAL cannot be used.

I disagree.  Please provide a concrete example of where this breaks.
 
> may be shimmed in.

TLS can also be shimmed in other places.

> use TLS without client certificates.

I am not proposing to use TLS without client certificates, I am using
the number of extant TLS implementations without client certificates to
support the arugument that client certificate management is
significantly harder to implement than TLS.

---

From: [email-masked] (John Myers)
Date: Wed, 07 Jun 2000 19:23:02 -0700