Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt]

From: "John Kennedy" <[email-masked]>
Date: Wed, 12 Jul 2000 10:52:09 -0700

Hi,

Another advantage of this scheme (and SASL, in general) is that the client
authentication mechanism need not have any relationship to the cipher suite used
in the TLS protocol.  For example, after an RSA-based, server-authenticated TLS
session is established, the ECDSA version of this SASL mechanism could be used
by a client to authenticate to the server.  In this way, existing server side
TLS and RSA-based PKI components can be retained while still permitting strong
authentication from clients for which ECDSA signing is a more
computationally-friendly authentication operation.  The ability to accomodate
such "hybrid" client-server authentication schemes without throwing out existing
server-authentication infrastructure (e.g.,code/certs) has a number of obvious
practical advantages.

On the other hand, the disadvantage of hybrid TLS+SASL approaches is that the
server's TLS layer alone is not able to provide on-going binding of client
identity to the server simply because it was not involved in client
authentication and the client's credentials are not incorporated into the TLS
authenticated key exchange.  Care must be taken on both sides of the link to
insure that relying party access control and other policy enforcement mechanisms
can "see" and correctly characterize channel security characteristics that are
implemented at different layers in the stack.  Hybrid, "cross-layer" schemes may
be practical, but can also be a double-edged sword.  This, of course, is only a
warning to implementors, not a criticism of the protocols themselves.

Regards,

-John Kennedy

Robert Zuccherato <[email-masked]> on 07/12/2000 08:01:18 AM

To:   [email-masked]
cc:    (bcc: John Kennedy/Certicom)

Subject:  FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt

Hi,

I just thought I would let the list know that Magnus and I have resubmitted
our draft describing a public-key based SASL mechanism.  We have addressed
some of the specific comments that people had and attempted to provide a
little bit more motivation.

As was discussed on this list earlier, the main motivation of this draft is
to provide authentication in environments where, for various architectural
reasons, the endpoint of the TLS session is not the same as the application
endpoint.  However, it was mentioned to us recently that our draft also
supports the situation where a user initially establishes a server-side
authenticated connection, browses around, and then requests a certain URL
which requires client authentication.  This mechanism allows this "upgrade"
in authentication without requiring a re-negotiation of the TLS session.

     Robert Zuccherato.