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

From: Chris Newman <[email-masked]>
Date: Tue, 06 Jun 2000 08:54:58 -0700

--On Tuesday, May 30, 2000 15:00 +0200 Magnus Nystrom 
<[email-masked]> wrote:
> FYI. Comments and feedback is welcome and solicited.

I skimmed the document.  I'm sorry I don't have time to chase down all the 
X.509/FIPS references necessary to grok the spec.

(1) It seems to have far too many things marked "OPTIONAL".  This makes the 
protocol more complex than necessary.  Preferably the only OPTIONAL items 
should be the differences between one-way and mutual auth.  RandomC 
certainly has no business being optional.

(2) I don't understand the value of this if the client cert is optional. 
Doesn't that mean the server has to store the certs for every possible 
client in order to guarantee interoperability?  Or am I missing something?

(3) I presume this factors in the DNS name of the server which the client 
intends to communicate with -- usually the only information the client has 
about the server.  Where can I read the rules for how that is used?  Is 
that put in the EntityB field?  Is the case where multiple physical servers 
answer for the same domain name considered?  Is it possible for each 
physical server to have a different private key in that case?

(4) I don't see a clear statement of how to determine the authorization 
identity (user to log in as, which may be different from the user whose 
private key is used).  If this is buried somewhere in X.509 specs, please 
draw attention to it in the spec.

(5) The reference to RFC 1738 should be updated to RFC 2396.

(6) Is there a fast re-authentication option, or should TLS be used when 
that's needed?  Note that many POP clients make a connection every 5 
minutes to check mail, and some IMAP clients make a new connection every 
time a new folder is opened so a fast re-authentication protocol could be 
important for scalability.

(7) Is there an open-source implementation of RFC 2459?  If not, this seems 
much more complex than TLS where I can just grab OpenSSL and let it do all 
the work.

(8) The IETF has a policy (the "Munich Mandate") which prohibits making 
patented algorithms mandatory to implement when there's and unpatented 
equivalent.  I consider the recommendation to implement the RSA algorithm 
inappropriate given that policy.  Since this is a set of mechanisms rather 
than a protocol, the recommendation is not necessary for interoperability 
so you could simply remove it.  Alternatively you could change it to 
recommend DSA, or wait until after September 20th for standardization.

		- Chris

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 6 Jun 2000 18:38:55 -0700

> -----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: Magnus Nystrom <[email-masked]>
Date: Wed, 7 Jun 2000 19:29:48 +0200 (MET DST)

Chris,

Many thanks for your comments and suggestions for improvements. My
response below.

> certainly has no business being optional.

Right, we will change this in the next draft.

> client in order to guarantee interoperability?  Or am I missing something?

Yes, client CertData should probably be mandatory.

> physical server to have a different private key in that case?

Yes it is. Only requirement is that the server is able to see that the
client intended to communicate with it - if, e.g., there is a round-robin
DNS, then for all intent and purposes involved servers are the same (from
the client's perspective). It could be that the DNS name is a SHOULD (or
even a MUST?).

> draw attention to it in the spec.

Correct, thanks for the observation. There should be an explicit,
but optional, authorization id included. If not included, the server will
have to use the authenticated id.

> (5) The reference to RFC 1738 should be updated to RFC 2396.

Right.

> important for scalability.

No, there is no fast re-authentication option. One could add one (for
example by letting the entities negotiate a session secret) but it is our
feeling that this would complicate the mechanism unnecessarily.
 
> much more complex than TLS where I can just grab OpenSSL and let it do all 

Certificate-handling open-source is certainly available,e.g. as part of
OpenSSL, and ssleay, but the Jonah PKIX freeware library is another
alternative, I guess.

> recommend DSA, or wait until after September 20th for standardization.

Right, the latter was (and is) our intent.

Thanks,
-- Magnus

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 9 Jun 2000 8:14:05 EDT

It seems to me that the fact that you have untrusted middlemen is 
even more reason why you would use TLS.  You do not trust them,
therefore you must protect your data end to end.  You allow the
middlemen to proxy, translate, ... the connection and then you
perform an end to end authentication and encryption.

> 
> Dear Paul,
> 
> No, I am not mis-speaking. There are in fact architectures like this.
> 
> -- Magnus
> 
> On Thu, 8 Jun 2000, Paul Leach wrote:
> 
> > 
> > 
> > > From: Magnus Nystrom [mailto:[email-masked]]
> > > Sent: Wednesday, June 07, 2000 10:26 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: I-D Action: draft-zuccherato-9798-3-sasl-00.txt
> > > 
> > > 
> > > 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,
> > 
> > Allowing an "untrusted" middleman to translate or re-format information
> > flowing through it smacks of a recipe for disaster. Surely you
> > mis-speak.
> > 
> > Paul
> > 
> 
> -- Magnus
> Magnus Nystrom		Email: [email-masked]
> RSA Security
> 
> 
> 

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 9 Jun 2000 09:22:16 -0700

> Sent: Friday, June 09, 2000 2:50 AM
> To: Paul Leach
> Cc: [email-masked]; [email-masked]

Well, then they are deliberately allowing untrusted parties, _including
malicious ones, against whom the proposal offers no protection_, to
access their communications. They don't need authentication at all, in
which case.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 10 Jun 2000 7:10:14 EDT

> Paul,
> 
> On Fri, 9 Jun 2000, Paul Leach wrote:
> > 
> > > Sent: Friday, June 09, 2000 3:04 AM
> > > 
> > > 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.
> > 
> > Why not? What stops any app that would use the proposed new
> > authentication protocol from making the two end points the same and
> > using TLS instead?
> > 
> > In fact, nothing does.
> 
> How about:
> A client uncapable of verifying certificates? A situation where unilateral
> authentication is enough?  A client uncapable of performing a full TLS
> handshake?
> 
> BR,
> -- Magnus
> 

Use a TLS cipher suite that does not use X.509 certificates for
authentication.  At the moment there is only Kerberos 5 defined as an
RFC but there is nothing to stop someone from defining a cipher suite
that uses something else.

Or you can use TLS in an anonymous mode if you have another
authentication mechanism that can prove shared knowledge of unverified
data.  If so, you take the TLS client finished message and the server
finished message and you verify them as part of the authentication
method.  That will ensure there is no MITM.

---

From: "Paul Leach" <[email-masked]>
Date: Sat, 10 Jun 2000 15:31:48 -0700

> Sent: Saturday, June 10, 2000 1:51 AM
> To: Paul Leach
> Cc: John Myers; Robert Zuccherato; [email-masked]

If your complaint is that TLS doesn't readily admit to reducing the
level of security, I would argue that TLS is easy enough to implement in
it entirety that that is an irrelevane argument, and that _less_
security isn't what the world needs right now.

Besides, as John pointed out, it is possible to handle those cases. And,
given the existence of open source TLS implementations, why would anyone
bother to implement a totally new package that has less security?

Paul

---

From: Chris Newman <[email-masked]>
Date: Tue, 06 Jun 2000 08:54:58 -0700

- Chris

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 6 Jun 2000 18:38:55 -0700

I concur completely.

Paul

---

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

Dear Paul and John,

-(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:

> > 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: Magnus Nystrom <[email-masked]>
Date: Wed, 7 Jun 2000 19:29:48 +0200 (MET DST)

Chris,

Right.

 

Thanks,
-- Magnus

---

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 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: "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

> 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: "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

>  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: "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

[...]

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: "Paul Leach" <[email-masked]>
Date: Thu, 8 Jun 2000 10:10:46 -0700

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 9 Jun 2000 8:14:05 EDT

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 9 Jun 2000 09:22:16 -0700

Paul

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 9 Jun 2000 13:14:54 -0700

> To: John Myers
> Cc: Robert Zuccherato; [email-masked]

In fact, nothing does.

Paul

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 10 Jun 2000 7:10:14 EDT

---

From: "Paul Leach" <[email-masked]>
Date: Sat, 10 Jun 2000 15:31:48 -0700

Paul