Simple Authentication and Security Layer (SASL)
draft-ietf-sasl-rfc2222bis-15

[Ballot discuss]
Holding a discuss for IANA, which expects to clear today.

Also, there is an ongoing discussion of whether 2119 language should
be used in section 6.  I'm holding a discuss until that completes.

[Ballot comment]
Please respond to Sam's satisfaction as Responsible AD (I don't need
to have an answer myself):

  The IESG may reassign responsibility for a SASL mechanism.  The most
  common case of this will be to enable changes to be made to mechanisms
  where the author of the registration has died, moved out of contact or
  is otherwise unable to make changes that are important to the
  community.

Is this an arbitrary grant of reassignment rights to the IESG?  Or just
of the standards track SASL mechanisms?  How well must the unreachability
be demonstrated before reassignment?  By what means?  This is not very
crisp, and when it comes time to actually take this action, it will need
to be implementable.  One thought would be to state that the IESG has
discretion to announce that the registrant has been found to be unreachable
and therefore the registration is changed.

IANA Last Call Comments:
Upon approval of this document the IANA perform the following actions:
Replace reference for RFC2222 at http://www.iana.org/assignments/sasl-mechanisms
Update the registration procedures to be as follows:
FCFS for Mechanisms
Expert Review with Mailing List for Family Name Registrations

Questions:
In the document it shows the following template:
      Subject: Registration of SASL mechanism X
      SASL mechanism name (or prefix for the family):
      Security considerations:
      Published specification (recommended):
      Person & email address to contact for further information:
      Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
      Owner/Change controller:
      Note: (Any other information that the author deems relevant may be
      added here .)

Does having the above template information change what appears (format) at the registry?
Currently only the Mechanism/Usage/Reference/Owner information is displayed?
Should this page be an HTML page with clickable links to either a document if that is what registers the mechanism or a template if registered by an individual?  Similar to the following:
http://www.iana.org/assignments/media-types/application/)

For the Family Name Registrations, is this meant to be a separate registry or within the same as above?
Are there any of these in the registry now?  If so, should there be another indicator?

The above relates to the comments, as these are not currently separate files, where would these comments go?  Somewhere within the registry at http://www.iana.org/assignments/sasl-mechanisms?
If they were separate files we could put comments there.

An expert will need to be appointed.

Other updates to make with the publication of this document:
  1) Change the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
  registrations to OBSOLETE.

  2) Change the "Published specification" of the EXTERNAL mechanism to
  this document as indicated below:

Shouldn't all those that reference RFC2222, have the reference changed to this document?

[Ballot comment]
sect 2, 2nd bullet seems to be an incomplete sentence?

In sect 1.1. I see:

  1.1.  Document Audiences

  This document is written to serve several different audiences:

    - protocol designers using this specification to support
      authentication in their protocol,

    - mechanism designers that define new SASL mechanisms, and

    - implementors of clients or servers for those protocols which
      support SASL.

  While the document organization is intended to allow readers to focus
  on details relevant to their engineering, readers are encouraged to
  read and understand all aspects of this document.

But I must say that I find it difficult to read it as a protocol
designer as per your first bullet.

-----

My successor Dan Romascanu also looked at this doc, and
I agree with his further comments/questions:

1. Clarification question:

Section 3.7

  Once the security layer is in effect in the protocol data stream, it
  remains in effect until either a subsequently negotiated security
  layer is installed, or the underlying transport connection is closed.


How is a subsequently negotiated security layer installed? I suppose
that one would aim to keep the operational continuity of a protocol in
cases of re-keying, as mentioned in section 6.3.  If this is supported,
how does it happen? Is the SASL exchange repeated, needs the underlying
transport connection be torn down? Should multiple successful SASL
authentication exchanges be permitted for this purpose?

2. In section 6.1..5 - Should not 'must not' and the second 'should' be
in capitals?

3. Section 7.1.1

While this registration procedures do not require expert review,
  authors of SASL mechanisms are encouraged to seek community review and
  comment whenever that is feasible.  Authors may seek community review
  by posting a specification of their proposed mechanism as an
  Internet-Draft.  SASL mechanisms intended for widespread use should be
  standardized through the normal IETF process, when appropriate.

I am wondering whether this process is not too loosely formulated. It
seems to leave the door open for somebody requiring the registration of
a mechanism directly from IANA without going necessarily through a
review that checks that requirements defined in Section 5 are met. Maybe
a mandatory referring to advice from a group of SASL experts or review
on  mailing list or by a Security AD would be useful.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

>> Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

>> Sam Hartman has solicited review from outside the Security area,
>> and the resulting comments were helpful for revising the document.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

>> No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

>> No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

>> The consensus appears to be reasonably solid.  The document has
>> been through two Last Calls recently, with far fewer issues raised
>> during the second Last Call.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

>> No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

>> The document passes id-nits except for having copyright notices in
>> both RFC 2026 and RFC 3978 forms.  This should be fixed in editing.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

>> References are split into normative and informative.  No normative
>> references cite Internet-Drafts.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

Technical Summary

    This document replaces RFC 2222 as the definition of the Simple
    Authentication and Security Layer (SASL), a framework for providing
    authentication and data security services in connection-oriented
    protocols via replaceable mechanisms.  SASL provides a structured
    interface between protocols and mechanisms.  The resulting framework
    allows new protocols to reuse existing mechanisms and allows old
    protocols to make use of new mechanisms.  The framework also
    provides a protocol for securing subsequent protocol exchanges
    within a data security layer.  This document also defines one SASL
    mechanism, the EXTERNAL mechanism.

Working Group Summary

    This document is a significant part of the goals of the SASL
    Working Group.  The document has been through a multitude of Last
    Calls during its lifetime, but the most recent Last Call resulted
    in predominantly editorial comments.

Protocol Quality

    The SASL protocol is used in many application protocols.  Multiple
    implementations of SASL framework exist in library form.

    Pekka Savola and David Black have performed reviews of this document
    from an outsider's perspective.  Their comments have been very helpful
    in pointing out problems with the document.