Subject: draft-josefsson-sasl-external-channel-01

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 01:52:27 +0200

All,

I've noticed some renewed interest in an EXTERNAL variant that refers to
an outer TLS channel, so I updated my earlier EXTERNAL-CHANNEL document.

There is one open issue: whether it is worthwhile to reference RFC 5056
for channel names, or whether the document should go ahead and define a
EXTERNAL-TLS mechanism directly.  That would refer directly to an outer
TLS channel.  It could also reserve EXTERNAL-* for other external
security channels.  I don't care strongly, but I do suspect that
interoperability will be better with the EXTERNAL-TLS approach (as there
are multiple channel names for TLS channels already, and more are
proposed).

/Simon

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism for External Authentication using a Named Channel: EXTERNAL-CHANNEL
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-01.txt
> 	Pages           : 9
> 	Date            : 2009-04-13
>
> This document describes a way to perform end-user authentication in
> the Simple Authentication and Security Layer (SASL) framework by re-
> using an external security layer (such as the Transport Layer
> Security (TLS) protocol) that may have already completed end-user
> authentication.  In comparison with the existing EXTERNAL mechanism,
> this mechanism alleviates the a priori assumptions made by the design
> of the EXTERNAL mechanism.  This mechanism transfers an identifier of
> the external channel to be used explicitly.
>
> See <http://josefsson.org/external-channel/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 13 Apr 2009 23:41:05 -0400

> are multiple channel names for TLS channels already, and more are

I think you have to encode the type of channel to be used for this in the 
mechanism name, so that it becomes part of the input to mechanism 
selection.  It would be poor for a client to select EXTERNAL-CHANNEL 
thinking it's going to get to use credentials from one channel type, only 
to discover that the server only supports some different type.

Unfortunately this does mean you need to register a distinct name for each 
channel type, but I think that's unavoidable anyway.  The thing we're 
interested in here is a channel type, not a channel binding type.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 09:56:59 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I think you have to encode the type of channel to be used for this in
> the mechanism name, so that it becomes part of the input to mechanism
> thinking it's going to get to use credentials from one channel type,
> only to discover that the server only supports some different type.
>
> Unfortunately this does mean you need to register a distinct name for
> each channel type, but I think that's unavoidable anyway.  The thing
> we're interested in here is a channel type, not a channel binding
> type.

I agree with that.  I have re-read the discussion around
external-channel-00 and it also leaned towards that approach.

Thus, I believe the way forward is to define a EXTERNAL-* mechanism
family and provide one instantiation as EXTERNAL-TLS.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 11:56:29 -0500

> family and provide one instantiation as EXTERNAL-TLS.

+1