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

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 13 Jul 2000 12:49:30 +1000

If the TLS endpoint is the server, I don't see what you mean about TLS not
being able to "provide on-going binding of client identity"? TLS itself
should be capable of preventing attacks on the communication.

In the case where the TLS enpoint is not the server, surely a
man-in-the-middle attack is feasible?

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

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.

---

From: "John Kennedy" <[email-masked]>
Date: Thu, 13 Jul 2000 10:48:31 -0700

If client authentication is not part of the TLS protocol then all the TLS layer
*by itself* provides is an encrypted channel to an unauthenticated client.
What you have is a unilaterally authenticated key exchange.  The SASL client
authentication has value but it does not get bound into the TLS session in a
cryptographic (or any other) sense.  Message authentication on packets from the
client is not included in the TLS session.  TLS may be protecting you against
snooping, but in this instance it is not providing any data source
authentication services to the server.

When you start stitching together cryptographic protocol services in a piecemeal
fashion the ability to inspect and prove the correctness of the system and the
properties of the "composed" secure channel becomes more difficult.  Instead of
looking at the TLS implementation or the SASL implementation independently, we
must now look at how they are combined within the endpoints.  It can be done (in
fact it is done all the time), I'm just pointing out that it has the inherent
*potential* of being less secure if implemented poorly or if the security
properties incorrectly assessed.

As for the MITM attack question, it is certainly a possibility anytime security
services are not "end-to-end". YMMV.

-John

"Ramsay, Ron" <[email-masked]> on 07/12/2000 07:49:30 PM

To:   John Kennedy/Certicom@Certicom, Robert Zuccherato
      <[email-masked]>
cc:   [email-masked], [email-masked]

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

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 14 Jul 2000 12:41:24 +1000

Accepted, thanks.

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Friday, 14 July 2000 3:49
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: TLS + SASL [was FW: I-D
ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt]

If client authentication is not part of the TLS protocol then all the TLS
layer
*by itself* provides is an encrypted channel to an unauthenticated client.
What you have is a unilaterally authenticated key exchange.  The SASL client
authentication has value but it does not get bound into the TLS session in a
cryptographic (or any other) sense.  Message authentication on packets from
the
client is not included in the TLS session.  TLS may be protecting you
against
snooping, but in this instance it is not providing any data source
authentication services to the server.

When you start stitching together cryptographic protocol services in a
piecemeal
fashion the ability to inspect and prove the correctness of the system and
the
properties of the "composed" secure channel becomes more difficult.  Instead
of
looking at the TLS implementation or the SASL implementation independently,
we
must now look at how they are combined within the endpoints.  It can be done
(in
fact it is done all the time), I'm just pointing out that it has the
inherent
*potential* of being less secure if implemented poorly or if the security
properties incorrectly assessed.

As for the MITM attack question, it is certainly a possibility anytime
security
services are not "end-to-end". YMMV.

-John

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

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 13 Jul 2000 12:49:30 +1000

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

---

From: "John Kennedy" <[email-masked]>
Date: Thu, 13 Jul 2000 10:48:31 -0700

-John

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 14 Jul 2000 12:41:24 +1000

Accepted, thanks.

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Friday, 14 July 2000 3:49
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: TLS + SASL [was FW: I-D

-John

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

From: "Ramsay, Ron" <[email-masked]>
To: John Kennedy <[email-masked]>
Cc: [email-masked]
Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt]
Date: Fri, 14 Jul 2000 12:41:24 +1000
Sender: [email-masked]

Accepted, thanks.

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Friday, 14 July 2000 3:49
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: TLS + SASL [was FW: I-D

-John

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

From: "John Kennedy" <[email-masked]>
To: "Ramsay, Ron" <[email-masked]>
cc: [email-masked]
Date: Thu, 13 Jul 2000 10:48:31 -0700
Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt]
Sender: [email-masked]

-John

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

From: "Ramsay, Ron" <[email-masked]>
To: John Kennedy <[email-masked]>, Robert Zuccherato <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-0 1 .txt]
Date: Thu, 13 Jul 2000 12:49:30 +1000
Sender: [email-masked]

Ron.

-----Original Message-----
From: John Kennedy [mailto:[email-masked]]
Sent: Thursday, 13 July 2000 3:52
To: Robert Zuccherato
Cc: [email-masked]; [email-masked]
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01
.txt]

Hi,

Regards,

-John Kennedy

To:   [email-masked]

Hi,

     Robert Zuccherato.

From: "John Kennedy" <[email-masked]>
To: Robert Zuccherato <[email-masked]>
cc: [email-masked], [email-masked]
Date: Wed, 12 Jul 2000 10:52:09 -0700
Subject: TLS + SASL [was FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01 .txt]
Sender: [email-masked]

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

To:   [email-masked]

Hi,

     Robert Zuccherato.

From: Robert Zuccherato <[email-masked]>
To: [email-masked]
Subject: FW: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt
Date: Wed, 12 Jul 2000 11:01:18 -0400
Sender: [email-masked]

Hi,

	Robert Zuccherato. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, July 11, 2000 6:31 AM
> Subject: I-D ACTION:draft-zuccherato-9798-3-sasl-01.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: ISO/IEC 9798-3 Authentication SASL Mechanism
> 	Author(s)	: R. Zuccherato, M. Nystrom
> 	Filename	: draft-zuccherato-9798-3-sasl-01.txt
> 	Pages		: 15
> 	Date		: 10-Jul-00
> 	
> This document defines a SASL [RFC2222] authentication mechanism based
> on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity
> authentication.  This mechanism only provides authentication using
> X.509 certificates [X509].  It has no effect on the protocol
> encodings and does not provide integrity or confidentiality services.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zuccherato-9798-3-sasl-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-zuccherato-9798-3-sasl-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-zuccherato-9798-3-sasl-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.