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

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

Folks,

I've updated the EXTERNAL-* draft to avoid referring to the channel
binding document for security channel names.  This made it easier to
discuss TLS specific items.

/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-02.txt
> 	Pages           : 9
> 	Date            : 2009-04-14
>
> This document describes a way to perform client authentication in the
> Simple Authentication and Security Layer (SASL) framework by
> referring to the end-user 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-02.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: Kurt Zeilenga <[email-masked]>
Date: Tue, 14 Apr 2009 12:48:05 -0700

Simon,

Overall, this I-D mets my needs.  Thanks!

One issue the I-D needs to discuss is how to establish additional  
EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC  
or EXTERNAL-IPC.  How are names of family members ensured to be  
unique?  etc.

I suggest that EXTERNAL-* family members be registered in the SASL  
mechanism name table under an Expert Review Required policy.  I rather  
not use "Specification Required" as that overly burdensome, and I  
don't see any particular reason for the IETF to have a monopoly on the  
design of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd  
likely do so outside of the IETF.)

In particular, I suggest adding another registration request for  
EXTERNAL-TLS to the the IANA considerations section and then adding  
the statement:

	Registration of additional members of this family requires Expert  
Review [BCPXXXX].

to the end of the section (replacing XXXX with the number of the BCP  
that defines Expert Review).

-- Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Apr 2009 15:54:02 -0400

--On Tuesday, April 14, 2009 12:48:05 PM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

> EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC or
> EXTERNAL-IPC.  How are names of family members ensured to be unique?  etc.
>
> not use "Specification Required" as that overly burdensome, and I don't
> see any particular reason for the IETF to have a monopoly on the design
> of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd likely do so
> outside of the IETF.)

Uh, generally Specification Required is _less_ restrictive than Expert 
Review, as it only requires that you provide a specification rather than 
requiring approval from someone.  Meeting the requirement means providing 
some form of specification; it does not require an RFC, let alone IETF 
approval.

That said, I agree with the approach, and with the notion that the IETF 
needn't have a monopoly on EXTERNAL-* mechanisms.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 15:08:23 -0500

> needn't have a monopoly on EXTERNAL-* mechanisms.

Moreover, we're not likely to have many more variants of EXTERNAL than
-TLS, -IPsec and -IPC.  Sure, I could see some SASL app tunneled over
HTTP with DIGEST-MD5 or HTTP/Negotiate, so maybe EXTERNAL-HTTP.  It's
unlikely that we'd have SASL apps over RPC protocols or over other SASL
apps.  Thus we can expect three, maybe four EXTERNAL-* variants.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 14 Apr 2009 14:08:24 -0700

On Apr 14, 2009, at 12:54 PM, Jeffrey Hutzelman wrote:

>
> --On Tuesday, April 14, 2009 12:48:05 PM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
>>
>> Simon,
>>
>> don't
> Uh, generally Specification Required is _less_ restrictive than  
> Expert Review, as it only requires that you provide a specification  
> rather than requiring approval from someone.

I note that RFC 5226 says "Specification Required also implies use of  
a Designated Expert".  Designated Expert is an alias for Expert Review.

Anyways, though a document can place all kinds of requirements upon  
what an "Expert Review" might cover, I was thinking of a review  
limited to the appropriateness of the request.  That is, no  
requirement (but no preclusion) that the Expert review anything  
outside the registration request.

I would be fine with Specification Required.  The difference doesn't  
matter much (to me).

> Meeting the requirement means providing some form of specification;  
> it does not require an RFC, let alone IETF approval.
>
>
> That said, I agree with the approach, and with the notion that the  
> IETF needn't have a monopoly on EXTERNAL-* mechanisms.
>
> -- Jeff
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 15 Apr 2009 13:19:36 +0200

> Overall, this I-D mets my needs.  Thanks!

Great.

> or EXTERNAL-IPC.  How are names of family members ensured to be

Having read the replies, and agreeing fully with Jeff's notion that the
IETF should not have a monopoly of EXTERNAL-* mechanisms, let me suggest
that we use a First-Come-First-Serve model.  It is important to ensure
uniqueness of mechanism names, and in my experience both expert review
and specification required models can delay or defer people to request a
mechanism name.  That is bad.  Further, I see strong benefit in the
expert reviewer or specification required model over FCFS.  Thoughts?

I don't care strongly which approach to use.  So I would be fine with
any of (in preference order) FCFS, specification required, or expert
review.  I do feel strongly that it should not be difficult to get a
IANA allocation.  We have plenty of bad experience with protocols that
has too rigid protocol number allocation policies.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Apr 2009 10:28:04 -0500

On Wed, Apr 15, 2009 at 01:19:36PM +0200, Simon Josefsson wrote:
> that we use a First-Come-First-Serve model.  [...]
> 

I don't care strongly either.  FCFS w/ specification required (but not
expert review, not standards action) seems like the best approach.

EXTERNAL is not exactly tricky, after all, so why demand, say, expert
review?

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 15 Apr 2009 09:31:32 -0700

> EXTERNAL is not exactly tricky, after all, so why demand, say, expert

Expert review is useful when it not feasible to let IANA to  
mechanically hand out assignments.

Expert review need not be heavy nor result in a denial.

     Additional names may be registered under Expert Review or IESG  
Approval [RFC5226].

     Registration of mechanisms detailed in IETF documents require  
IESG Approval.  The IESG Approval route
     is also open to others, such as those whose requests were denied  
under the Expert Review route.

     The Designated Expert will review only the appropriateness of the  
requested name for the requested purpose.
     No specification is required.  Where a specification is provided,  
the particulars of the specification are
     not to be considered by the Designated Expert.  Where the  
Designated Expert finds the requested name to be inappropriate,
     the Designated Expert should recommend a more appropriate name  
within the family and, if acceptable by the requestor, this
     name will be registered without any further review.  In hopefully  
rare cases where the Designated Expert finds the request
     wholly unacceptable (for instance, when the stated purpose has  
nothing to do with the purpose of the family), the
     Designated Expert may deny the request.  Actions of the Expert  
are appealable [RFC2026].

That is, the Reviewer should avoid reviewing the particulars of the  
mechanism and simply focus on whether the requested name is sensible  
for the requested purpose.  IANA prefers not to make such judgements,  
hence the need for Expert Review.

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 18 Apr 2009 11:54:23 +0200

> mechanically hand out assignments.

What problem do we want to solve by not letting IANA hand out
assignments on a FCFS basis?

> hence the need for Expert Review.

I don't understand how anyone can come to the conclusion that a name is
unacceptable for a purpose without reviewing the particulars of the
mechanism?  Could you give a concrete example?

The only threats I see to a FCFS approach are along these lines:

- Someone overloads IANA with one request every day
- Someone registers EXTERNAL-<offensive word>
- Someone registers EXTERNAL-<viagraspam.com>

The cost of accepting or dealing with problems like that, in the context
of registering EXTERNAL-* SASL mechanism names, appears to be low.  The
cost of implementing and handling appeals and expert review issues can
be significant and time consuming.

Again, I don't feel strongly about this, but if there is nothing else to
discuss around the draft, that seems like a good sign. ;)

/Simon

---

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

> expert review, not standards action) seems like the best approach.

That would work.  It requires some effort on the person registering the
name, and anyone well intended to register a EXTERNAL-* name should be
able to spend the time to write down a specification for it.

Unfortunately RFC 5226 requires for "specification required" that the
specification is possible to implement in an interoperable way.  It also
requires a designated expert to evaluate.  That can be a quite delicate
issue, and I don't see what is gained by adding this.

The explanation in RFC 5226 for FCFS seems to describe the intent with
what you describe:

      First Come First Served - Assignments are made to anyone on a
            first come, first served basis.  There is no substantive
            review of the request, other than to ensure that it is
            well-formed and doesn't duplicate an existing assignment.
            However, requests must include a minimal amount of clerical
            information, such as a point of contact (including an email
            address) and a brief description of how the value will be
            used.  Additional information specific to the type of value
            requested may also need to be provided, as defined by the
            namespace.  For numbers, the exact value is generally
            assigned by IANA; with names, specific text strings can
            usually be requested.

            Examples: SASL mechanism names [RFC4422], LDAP Protocol
            Mechanisms, and LDAP Syntax [RFC4520].

The "brief description of how the value will be used" is the level of
detail that I believe we want to require.

Given that we already use FCFS to register SASL mechanism names, and
there haven't been any problems, I don't see any reason to use anything
more onerous to register EXTERNAL-* mechanism names.

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 18 Apr 2009 06:13:39 -0700

> assignments on a FCFS basis?

My concern is that someone will request the registration of a name in  
the family name space for a mechanism which doesn't fit well into that  
family.  I don't think specification review is requires to address  
this concern, but I do think review of the purpose of the requested  
name for the requested purpose.  I prefer that the RFC 4422, 7.1.2  
procedures used to register a family of mechanism be used in  
registering names within that family.

I suspect the 7.1.1 procedures (which are FCFS) if applied here would  
likely work out okay in practice as the IANA practice seems to be "ask  
for help" in adding items to rarely used tables.  So I don't object to  
use of FCFS here.

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 19 Apr 2009 06:27:47 +0200

Kurt Zeilenga <[email-masked]> writes:

> family.

Thanks for explaining, now I understand the concern better.  Still, I
don't think the human work needed to define/review instructions for
experts, assigning and replacing the expert, and dealing with the
potential of appeals, is motivated here.  The harm caused by a mistaken
registration is low.  Well intended people will listen to reason if we
can present good arguments, and eventually, we can't stop anyone from
using any mechanism name anyway.

I think the IESG have better things to do than responding to appeals
over an expert decision for this mechanism family.  The costs of IESG
appeals are high, the cost of even clearly bogus registrations is low.

The document could try to explain this issue further, and request people
more strongly to ask for review before requesting an assignment.  But I
think the current text is sufficiently clear already.

> for help" in adding items to rarely used tables.  So I don't object to

Thanks.

/Simon