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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 8 Jun 2000 12:56:07 +1000

An example.

We are going to attempt an authenticated logon through a DMZ. Therefore, we
have my host, HostA, the DMZ host, HostB, and the destination host, HostC.

I connect to HostB (thinking that it is HostC, if I understand how a DMZ
works) using TLS and receiver a server certificate. I'm using SASL/EXTERNAL,
so I send my client certificate. The connection is established.

I logon, specifying SASL/EXTERNAL. HostB receives the logon and passes it to
HostC. HostC does not have my client certificate and rejects the logon.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 8 June 2000 12:23
To: [email-masked]
Subject: Re: I-D Action: draft-zuccherato-9798-3-sasl-00.txt

"Ramsay, Ron" wrote:
> 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).

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

TLS can also be shimmed in other places.

> I also can't understand references to SASL services and then proposing to
> 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 20:20:50 -0700

Ah, it's as I thought.  Mr. Nystrom's statement:

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

is entirely false.  The middlemen want to eavesdrop on and spoof the
plaintext, so you're trying to negotiate a level of security that is
lower than TLS permits.

What we do in this situation is instead of having HostB forward the
EXTERNAL authentication to HostC, we have HostB perform its own SASL
negotiation with HostC, using whatever SASL mechanism it wants,
providing its own credentials, and passing HostA's user's identity in
the authorization id field.  TLS can be used between HostB and HostC or
not, depending on the site's security requirements.

---

From: [email-masked] (John Myers)
Date: Wed, 07 Jun 2000 20:20:50 -0700