Subject: Summary of 2222bis WGLC

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 24 Sep 2004 12:40:30 -0700

The chairs initiated a SASL Working Group Last Call on the
document:

  Title: Simple Authentication and Security Layer (SASL)
  Editor: A. Melnikov
  Filename: draft-ietf-sasl-rfc2222bis-08.txt

on 21 July 2004.  The last call period, though originally
scheduled to close 13 August 2004, was extended to allow
additional review and discussion.  All comments received
prior to the posting of this summary were considered.
The last call period is now closed.

ISSUE SUMMARY

Below is a summary of the issues of substance raised. For
each, the chairs provide a statement of regarding the
actions it believes are/aren't supported by WG consensus.
Additionally, a number of editorial issues were raised
and referred to the Editor for appropriate action.

1) Re-keying of security layers 

Nico indicated that the I-D did not discuss Re-keying of
security layers and suggested text in this area be added.
The WG discussed a number of specific suggestions in this
area, with the following text being the last version
submitted for WG consideration:
    SASL mechanisms that support re-keying SHOULD:
    - indicate that re-keying is or will be needed immediately;
    - provide re-keying messages or transparently include re-keying
      messages in the security layers; the latter can happen without
      application involvement, but only as long as the application is
      engaged in timely bidirectional exchanges with its peer.

The chairs believes the WG supports addition of this text.

2) Detail Hiding

Sam indicated the I-D claims that the layer does not generally
hide the details of mechanisms from protocols and suggested
this was an accurate reflection of what the WG intended to
state.  He suggested the I-D to be revised to state that
while the layer hides the details of protocols from mechanisms
and the details of mechanisms from protocols, it does not hide
the details of mechanisms from protocol implementations.

The chairs conclude the WG supports revising the I-D as
Sam suggests here.

3) Confidentiality and Integrity

Sam indicated that the I-D states "confidentiality protection
usually implies integrity protection" and that this was less than
ideal from a security standard point.  He suggested that the
word 'usually' be deleted.  Nico suggested revising the
specification to explicitly require future mechanisms which
provide a confidentiality protection service to provide include
integrity protection with that service.

The chairs conclude the WG supports revising the I-D as Sam
suggests here.

The chairs conclude that the WG supports allowing mechanisms to
"offer other kinds of security services" and hence does not
adding the requirement upon future mechanisms suggested by Nico.

4) Channel Binding

Nico asked whether the I-D should include text regarding
channel binding issues.  He suggest security consideration
text that clients using SASL over TLS should verify
the server's TLS identity to prevent MITM attacks.
He also suggested adding text encouraging future
mechanisms support channel bindings.

The chairs conclude that the WG supports the former
suggestion but not the latter.

5) Identities and Authorization

Kurt indicated that the I-D use of term "authorization
identity" is confusing and suggested use of different
terms for each distinct use of this term.  Jeffery
suggested using the terms:
	"authentication identity" to refer to the
	identity associated with the users creditials,
	"requested identity" to refer to identity
	which the user requests to act as, and
	"authorization identity" to refer to identity
	used by the server in making authorization
	decisions.  (The latter being derived from
	by former two.)

The chairs conclude the WG supports use of this
suggested terminology.

6) Empty initial response I

Ken suggested that the SHOULD in "the protocol profile
SHOULD also describe how an empty initial response is
encoded" ought to be a MUST.

The chairs conclude the WG supports this change.

7) Empty initial response II

Ken asked whether the I-D should explicitly state that
the profile also needs to describe how *empty* server
challenges and client responses as encoded.  Alexey
respond as to why he believes the I-D is sufficiently
clear here.

The chairs that the WG supports making no change here.

8) EXTERNAL use of external information

Ken suggested replacing "authenticate as" in the I-D text:
  The server uses information, external to SASL, to
  determine whether the client is permitted to authenticate
  as the authorization identity.
with "have the access privileges of".  Alexey suggested
it be replaced with "to act as".

The chairs conclude the WG supports this the change
suggested by Alexey. 

GENERAL CONCLUSION and NEXT STEPS

The chairs believe that WG consensus supports a recommendation
of this I-D, once the above issues are appropriate addressed,
to the IESG for publication as a Proposed Standard replacing
RFC 2222.  The chairs believes its above conclusions regarding
supported actions accurately reflect WG consensus and hence
direct the Editor to prepare a revision making the changes
for which chairs have indicated are supported by the WG.

The chairs believes its above conclusions regarding supported
actions accurately reflect WG consensus.  If you believe the
chairs have misread consensus, please indicate so by email
as soon as possible.  If you believe the above summary is
incomplete, please indicate by email as soon as possible.

After giving the WG sufficient time (1 week) to verify that
the actually changes made are consistent with WG consensus,
the chairs intend to recommend the revised I-D to the IESG
for consideration as a Proposed Standard.  The chairs do
not foresee the need to subject this I-D to another WG
Last Call.

Kurt & Sam, SASL co-chairs