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

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

But then you are NOT using SASL/EXTERNAL because HostC is simply validating
HostB and not HostA!

For example, if we were using X.509 authentication, the certification path
and token would actually travel end-to-end and HostC would indeed receive
credentials from HostA.

This really IS an application protocol. What you are talking about is a link
protocol. Your remarks about TLS being a session or application protocol are
simply wrong.

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

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

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 21:55:15 -0700

> But then you are NOT using SASL/EXTERNAL because HostC is simply validating

In the example I provided in my last message, I am using EXTERNAL
between HostA and HostB.  Any SASL mechanism, including EXTERNAL, that
supports an authorization id field can be used between HostB and HostC.

This is analogous to the example you provided, since that example showed
a TLS security association being established between HostA and HostB.

> and token would actually travel end-to-end and HostC would indeed receive

If you instead want to establish a security association between HostA
and HostC, then HostB should forward the TLS records through between
HostA and HostC.

> protocol. Your remarks about TLS being a session or application protocol are

I'm sorry, I don't see the argument behind these assertions.  What
difference between TLS and SASL makes TLS a "link" protocol as opposed
to an "application" protocol?

In your HostA, HostB, HostC situation, how would you handle a SASL
negotiation using a mechanism that provides perfect forward secrecy of
the identity being authenticated?

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 9 Jun 2000 12:04:21 +0200 (W. Europe Daylight Time)

Dear John,

> and HostC, then HostB should forward the TLS records through between

The TLS endpoint isn't always the same as the application endpoint and
that is the very reason for this proposal. Maybe this should be made more
explicit in the draft.

> to an "application" protocol?

IMHO, since it is possible to "insert" SASL in many higher-level protocols
it is a useful mechanism when, for one reason or another, lower level
protocols (I include TLS here) terminates at a gateway or similar, or the
application using the SASL-enabled protocol is unable to run TLS for one
reason or another, but is still capable of doing public-key operations.
 
> the identity being authenticated?

Just so we are talking about the same thing here: Perfect forward secrecy
= Disclosing one key/authentication does not give an attacker the
possibility to reuse that information in subsequent exchanges.

The proposed protocol is vulnerable to session hi-jacking, this fact is
also mentioned in the draft, and true also for other SASL mechanisms not
inserting a security layer.

-- Magnus

---

From: [email-masked] (John Myers)
Date: Sat, 10 Jun 2000 13:38:41 -0700

> that is the very reason for this proposal. Maybe this should be made more

What is HostA authenticating to, HostB or HostC?  Whenever I address one
case, you counter with an argument about the other.

If the TLS endpoint isn't the same as the application endpoint, you have
the TLS endpoint authenticate to the application endpoint using its own
credentials, passing the original client's identity in the authorization
ID.  This results in much better security, as only middlemen the
application endpoint is configured to trust are permitted to eavesdrop
or modify the the connection.

> reason or another, but is still capable of doing public-key operations.

One can also "insert" TLS in higher-level protocols.  See RFC's 2817,
2595, and 2487.  TLS is no different than SASL in this regard.

How does the theoretical existence of applications which support SASL
and public-key operations make TLS a "link" protocol but not an
"application" protocol?  There do exist applications which support TLS
and public-key operations, but are unable to run SASL for one reason or another.

> possibility to reuse that information in subsequent exchanges.

Exactly.  Consider a SASL mechanism where the client and server first
perform a Diffie-Hellman key exchange.  The client then sends the server
his cert encrypted with the Diffie-Hellman key and an authenticator
formed by signing the Diffie-Hellman key with his private key.

Or just explain how in your HostA, HostB, HostC situation you would
handle a Kerberos authentication which negotiates a privacy security
layer.  I brought up the issue of perfect forward secrecy of the
identity being authenticated to prevent the answer where HostB and HostC
both have access to the server key.

> inserting a security layer.

Most of the other SASL mechanisms which don't have a security layer
don't have it because they are incapable of negotiating a session key. 
The thing I don't like about this particular proposal are the
implications that this lack of security layer somehow improves security
or makes it significantly easier to implement than TLS.

---

From: [email-masked] (John Myers)
Date: Wed, 07 Jun 2000 21:55:15 -0700

---

From: Magnus Nystrom <[email-masked]>
Date: Fri, 9 Jun 2000 12:04:21 +0200 (W. Europe Daylight Time)

Dear John,

 

-- Magnus

---

From: [email-masked] (John Myers)
Date: Sat, 10 Jun 2000 13:38:41 -0700