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

From: Simon Josefsson <[email-masked]>
Date: Sat, 18 Apr 2009 12:44:09 +0200

Folks,

I've posted another update.  Primarily it adds new IANA considerations,
using almost the same text as RFC 4422 for registering normal SASL
mechanism names.

Complete diff:
http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html

/Simon

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism Family for External Authentication: EXTERNAL-*
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-03.txt
> 	Pages           : 10
> 	Date            : 2009-04-18
>
> This document describes a way to perform client authentication in the
> Simple Authentication and Security Layer (SASL) framework by
> referring to the client authentication provided by an external
> security layer.  We specify a SASL mechanism family EXTERNAL-* and
> one instance EXTERNAL-TLS that rely on the Transport Layer Security
> (TLS) protocol.  This mechanism differs to the existing EXTERNAL
> mechanism by alleviating the a priori assumptions that servers and
> clients needs somehow negotiate out of band which secure channel that
> is intended.  This document also discuss the implementation of
> authorization decisions.
>
> 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-03.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: Nicolas Williams <[email-masked]>
Date: Tue, 21 Apr 2009 15:17:06 -0500

> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt

A few comments:

 - I doubt today there's ever any cases where there could confusion as
   to what channel "EXTERNAL" refers to.  The confusion and the need for
   a priori agreement is theoretical -- if so then the text should
   probably reflect that, otherwise examples should be given.

 - When "EXTERNAL" is used one would think that the highest-layer,
   innermost end-to-end channel is the one it ought to refer to.  It
   strikes me as a good idea to state that.

 - An informative reference to TLS (RFC5246) seems necessary.  (Or maybe
   even normative.)

 - The string "a002" in the example given should probably be explained,
   or even removed (it seems superfluous, besides, application protocol
   bindings of SASL are not needed in order to have an example, no?).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Apr 2009 12:24:00 +0200

>    probably reflect that, otherwise examples should be given.

I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
refers to needs to be arranged out of band.  The point of this document
is to move the negotiation in band.  Since RFC 4422 rules the
negotiation out of scope, there is by definition always confusion which
channel is intended, and even on successful authentication there is in
practice no in-band guarantees that both sides intended the same
channel.

Maybe Kurt could describe his use case?

>    strikes me as a good idea to state that.

This is mentioned in section 3 for EXTERNAL-TLS.  I believe this belongs
in each EXTERNAL-FOO mechanism rather than in the generic framework, but
I agree that this needs to be stated.  I have added this section:

  <t>The external security channel to use is implied by the SASL
    mechanism name.  The channel has to be uniquely identifiable at
    both cliend and server side.  This means that mechanisms
    registered in this family MUST detail which channel should be
    chosen if there are layered channels of the same type.</t>

>  - An informative reference to TLS (RFC5246) seems necessary.  (Or
>  maybe even normative.)

I've made it normative.  (There was an informative reference.)

>    or even removed (it seems superfluous, besides, 

It can't be removed, or the example wouldn't be valid ACAP, if I
understand correctly.  The same is in RFC 4422.  I don't think we need
to explain the ACAP protocol.  But maybe I'm missing something...

>  application protocol bindings of SASL are not needed in order to have
>  an example, no?).

...because I don't understand what you mean here, explain?

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Apr 2009 11:08:56 -0500

On Wed, Apr 22, 2009 at 12:24:00PM +0200, Simon Josefsson wrote:
> [...]

That's what it says, but does anyone ever do that, or does everyone take
EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
the latter.

>     chosen if there are layered channels of the same type.</t>

OK.

> I've made it normative.  (There was an informative reference.)

OK.

> to explain the ACAP protocol.  But maybe I'm missing something...

Ah, ACAP.  But you don't need a specific application for the example.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Apr 2009 22:26:41 +0200

> EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's

Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
recall correctly) use EXTERNAL for localhost based authentication.  Some
applications probably use EXTERNAL for client-TLS too.

> Ah, ACAP.  But you don't need a specific application for the example.

We could add other examples too, but I don't see a point in removing the
current examples.  They are only examples, after all.  That text is
copied directly from RFC 4422, so I think it is useful to preserve for
historic comparisons too.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Apr 2009 15:41:51 -0500

> applications probably use EXTERNAL for client-TLS too.

But my earlier point stands: it's never the case, today, that there's
any confusion as to what EXTERNAL means.  A rule can be stated to
clarify what EXTERNAL means in future cases where there would be
confusion.

> historic comparisons too.

Was there a reference to ACAP?  If not, add an informational one :)

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Apr 2009 23:07:52 +0200

> clarify what EXTERNAL means in future cases where there would be

Today the client can never know what mechanism the server used.  The
server can never know what mechanism the client intended to be used.  So
I think we disagree that there is confusion what EXTERNAL means today.
Reducing that perceived confusion is the point of the draft.

> Was there a reference to ACAP?  If not, add an informational one :)

There is one already.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Apr 2009 16:19:54 -0500

> Reducing that perceived confusion is the point of the draft.

If it can only have meant one thing then there can be no confusion.

Confusion enters the picture when there can have been multiple answers.

Also, why should the client care which ID was used as long as the client
requested a specific authzid?  :)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Apr 2009 18:03:15 -0400

--On Wednesday, April 22, 2009 04:19:54 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> >> > That's what it says, but does anyone ever do that, or does everyone
>> >> > take EXTERNAL to mean "use the user authenticated by TLS"?  I
>> >> > suspect it's the latter.
>> >>
>> >> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils,
>> >> if I recall correctly) use EXTERNAL for localhost based
>> >> authentication.  Some applications probably use EXTERNAL for
>> >> client-TLS too.
>> >

If there is an a priori agreement as to what EXTERNAL is for, then there is 
no confusion.

Lacking such agreement, the only way you can know what EXTERNAL means is if 
it always means the same thing.  If that were the case (for example, if it 
always meant "use TLS") and it were simply undocumented, then it would be 
appropriate to amend the definition of EXTERNLA to say what it means.  But 
in fact, it appears that it does _not_ always mean the same thing.

We could say "it means use the highest-layer e2e channel", but that would 
be a backward-incompatible change, since it doesn't always mean that now.

We could say "it means use TLS, except when it doesn't", which would be 
very close to the deployed reality today.  Unfortunately, the "except when 
it doesn't" has the effect that this statement is not semantically 
different from what the current spec says -- you still have to know whether 
it means TLS, and if not, what else it means instead.

So, I think amending EXTERNAL is a lost cause, and we should just punt and 
concentrate on EXTERNAL-*.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Apr 2009 10:04:37 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> So, I think amending EXTERNAL is a lost cause, and we should just punt
> and concentrate on EXTERNAL-*.

Agreed.  Perhaps the background hasn't been clear: I considered to
publish an update of EXTERNAL with clarified semantics, i.e., "use
client credentials from the highest layered TLS channel".  However, I
think this WG has seen enough attempts to retrofit slightly modified
semantics on CRAM-MD5 and DIGEST-MD5 already (although we succeeded with
PLAIN).  My primary use case is to get client-TLS credentials reused in
SASL, so an update to EXTERNAL would have worked for me.  If someone
wants to drive that effort, I would be happy if it succeeded.  I believe
that is unlikely to succeed, because EXTERNAL appears to be deployed
with incompatible semantics already.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Apr 2009 10:08:28 +0200

> Confusion enters the picture when there can have been multiple answers.

Right, and I believe there is sufficient potential for multiple answers
to warrant work on EXTERNAL-*.

> requested a specific authzid?  :)

In some cases the client does not specify an authzid.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 23 Apr 2009 08:48:12 -0500

> it always means the same thing.  If that were the case (for example, if it 

Or if it could only reasonably mean one thing.

> in fact, it appears that it does _not_ always mean the same thing.

I can't see when the client and server could be confused _today_ by what
EXTERNAL means.

> be a backward-incompatible change, since it doesn't always mean that now.

Only if that actually changes EXTERNAL in any presently feasible
scenarios.

> concentrate on EXTERNAL-*.

I'm not arguing otherwise.  I'm arguing that we can also clarify
EXTERNAL.

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 23 Apr 2009 11:46:51 -0700

> Maybe Kurt could describe his use case?

Well, basically, it comes down to limitation that RFC 4422 states  
EXTERNAL has:

    In absence of some a
    priori agreement between the client and the server, the client  
cannot
    make any assumption as to what external means the server has used to
    obtain the client's credentials, nor make an assumption as to the
    form of credentials.

So, for instance, if a client established an identity using TLS (over  
TCP/IP), the client cannot assume the server pulls from TLS.  It just  
as well be pulling an identity from IP (the client's IP address).  As  
you noted in a subsequent post, an implementation might pull up the IP  
address to associate a "localhost" identity with the client.  This  
same issue happens when the client does TLS over IPC.  The client  
cannot know if the identity pulled up is from TLS or IPC layer.

Now, in many cases, the client may not care from where the server  
pulls.  It seems more likely if the client would care about what  
identity was associated to it by the server instead of the where.  For  
this, application protocols can offer "who am i?" operations.   Note  
that "who am i?" was actually introduced to solve a bit different  
issue... the issue that client cannot make assumptions about the  
identity a client associated with the credentials (even when those  
credentials include an user identifier).

I think EXTERNAL is generally "good enough", especially when combined  
with "who am i?" operations.

The use case I was thinking of was "Client wants to server to pull up  
from a particular layer (usually the layer immediately below the  
application layer protocol (e.g., TLS))".

-- Kurt