Subject: Re: A note about channel bindings
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Date: Mon, 30 Jan 2006 11:13:10 -0600
List-Id: <ietf-sasl.imc.org>

On Mon, Jan 30, 2006 at 11:11:00AM -0600, Nicolas Williams wrote:
> In terms of bits in GSS_Wrap() input, client-side in client-sends-first
> case:
> 
>     <sec layer pref -- 1 octet>
>     <sec layer pref with channel binding -- 1 octet>
>     <max output_size -- 4 octets>

and the authzid goes here...

>     <cbindings length -- 4 octets>
>     [<cbindings octets>]
>     [... -- extensibility :)]
> 

[...]
> The replies are:
> 
> client-reply:
> 
>     <sec layer selection - 1 octet>
>     <max output_size -- 4 octets>

and here.

>     [... -- extensibility :)]

Date: Mon, 30 Jan 2006 11:11:00 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: A note about channel bindings
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Jan 30, 2006 at 09:11:05AM -0500, Jeffrey Hutzelman wrote:
> On Monday, January 30, 2006 01:50:28 PM +0100 Simon Josefsson 
> <[email-masked]> wrote:
> >
> >>It may be that the best thing to do for SASL/GS2 channel bindings is
> >>that the first wrap token should include the channel bindings, if any,
> >>and security layers preferences for the cases that the binding succeeds
> >>and for when it fails, and the second wrap token should indicate binding
> >>success/failure and cause security layer selection accordingly.
> >
> >I believe I understand the point, but I'm not sure how to implement
> >this.  How do the server and client gracefully find out whether
> >channel binding negotiation succeeded?
> 
> You don't.  What Nico is proposing is that you ignore the GSSAPI channel 
> binding mechanism, and handle it yourself by including the channel 
> identifying information among the data sent in the first GSS_wrap() token.

Exactly.  The client send its channel bindings data and security layers
preferences [for channel bindings OK, channel bindings not OK] and the
server validates the channel bindings and selects a security layer as
per the client's preferences and channel binding status (success/failure).

In terms of bits in GSS_Wrap() input, client-side in client-sends-first
case:

    <sec layer pref -- 1 octet>
    <sec layer pref with channel binding -- 1 octet>
    <max output_size -- 4 octets>
    <cbindings length -- 4 octets>
    [<cbindings octets>]
    [... -- extensibility :)]

and server-side in server-sends-first:

    <sec layer pref -- 1 octet>
    <sec layer pref with channel binding -- 1 octet>
    <max output_size -- 4 octets>
    <cbindings length -- 4 octets>
    [<cbindings octets>]
    <sasl mech list length -- 4 octets>
    [<sasl mech list string>]
    [... -- extensibility :)]

The replies are:

client-reply:

    <sec layer selection - 1 octet>
    <max output_size -- 4 octets>
    [... -- extensibility :)]

and server-reply:

    <sec layer selection - 1 octet>
    <max output_size -- 4 octets>
    <sasl mech list length -- 4 octets>
    [<sasl mech list string>]
    [... -- extensibility :)]

The sasl mech list is a trivial item to throw in that optimizes
negotiation protection as recommended in rfc2222bis (get the list before
and after and compare) without overly complicating the implementation;
clients wouldn't have to do anything with it other than make it
available to applications.

Pick a byte order for the length fields.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Subject: Re: A note about channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 30 Jan 2006 15:22:51 +0100
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

>>> It may be that the best thing to do for SASL/GS2 channel bindings is
>>> that the first wrap token should include the channel bindings, if any,
>>> and security layers preferences for the cases that the binding succeeds
>>> and for when it fails, and the second wrap token should indicate binding
>>> success/failure and cause security layer selection accordingly.
>>
>> I believe I understand the point, but I'm not sure how to implement
>> this.  How do the server and client gracefully find out whether
>> channel binding negotiation succeeded?
>
> You don't.  What Nico is proposing is that you ignore the GSSAPI
> channel binding mechanism, and handle it yourself by including the
> channel identifying information among the data sent in the first
> GSS_wrap() token.

Aha, thanks for the explanation.

As I understand it, the acceptor will send:

GSS_Wrap (client_qops, client_maxbuf, [authzid],
          [chanbinding client_qops_failed_chanbinding])

client_qops_failed_chanbinding is used as the client qops bitmask if
the server cannot establish the channel binding, otherwise the
client_qops bitmask is used.

I'll try to incorporate this.

Regards,
Simon

Date: Mon, 30 Jan 2006 09:11:05 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: A note about channel bindings
Originator-Info: login-token=Mulberry:016hXwxVR9ZTk2YGhGHZMgNIGHJ/BxSWlXih4qIJU=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, January 30, 2006 01:50:28 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

>
> I'm revising the SASL GS2 document.  Live edits are available from:
>
> http://josefsson.org/sasl-gs2/
>
> I'm following up on this comment below.
>
> Nicolas Williams <[email-masked]> writes:
>
>> Sam points out that in SASL what we want out of channel binindings is to
>> affect the negotiation of security layers.  If a channel being bound to
>> provides integrity and confidentiality protection then the application
>> won't want to use a SASL mechanism's own security layers -- it's a
>> waste.
>
> Agreed.
>
>> In the GSS-API world there's no security layers -- just per-message
>> tokens, and which to use, if any, is entirely up to the application, but
>> in the SASL world SASL is involved in the negotiation of post-
>> establishment session protection.
>
> Right.
>
>> It may be that the best thing to do for SASL/GS2 channel bindings is
>> that the first wrap token should include the channel bindings, if any,
>> and security layers preferences for the cases that the binding succeeds
>> and for when it fails, and the second wrap token should indicate binding
>> success/failure and cause security layer selection accordingly.
>
> I believe I understand the point, but I'm not sure how to implement
> this.  How do the server and client gracefully find out whether
> channel binding negotiation succeeded?

You don't.  What Nico is proposing is that you ignore the GSSAPI channel 
binding mechanism, and handle it yourself by including the channel 
identifying information among the data sent in the first GSS_wrap() token.

-- Jeff

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: A note about channel bindings
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 30 Jan 2006 13:50:28 +0100
Sender: [email-masked]

I'm revising the SASL GS2 document.  Live edits are available from:

http://josefsson.org/sasl-gs2/

I'm following up on this comment below.

Nicolas Williams <[email-masked]> writes:

> Sam points out that in SASL what we want out of channel binindings is to
> affect the negotiation of security layers.  If a channel being bound to
> provides integrity and confidentiality protection then the application
> won't want to use a SASL mechanism's own security layers -- it's a
> waste.

Agreed.

> In the GSS-API world there's no security layers -- just per-message
> tokens, and which to use, if any, is entirely up to the application, but
> in the SASL world SASL is involved in the negotiation of post-
> establishment session protection.

Right.

> It may be that the best thing to do for SASL/GS2 channel bindings is
> that the first wrap token should include the channel bindings, if any,
> and security layers preferences for the cases that the binding succeeds
> and for when it fails, and the second wrap token should indicate binding
> success/failure and cause security layer selection accordingly.

I believe I understand the point, but I'm not sure how to implement
this.  How do the server and client gracefully find out whether
channel binding negotiation succeeded?

The GSS_S_BAD_BINDINGS error is fatal, as far as I can tell.  Should
the GSS negotiation restart at that point?  How do the acceptor tell
the initiator (and vice versa) when that happens?

The simplest may be that the initiator re-start the entire SASL GS2
authentication attempt, without a channel binding, if the first
attempt fails due to a BAD_BINDINGS error.  I'm not sure it is useful
to be more complex on this.  I will add a section describing this
logic, unless I see more concrete solutions.

Further, I stumbled over RFC 2744 paragraph 3.11:

   Some mechanisms may include the actual channel binding data in the
   token (rather than just a MIC); applications should therefore not
   use confidential data as channel-binding components.

Does this suggest that mechanisms may not even be integrity protecting
the channel binding data?  E.g., could CRC-32 be used to "check" the
channel binding integrity?  I cannot find other discussion about this
in RFC 2743 and RFC 2744.

Thanks.

Date: Tue, 24 Jan 2006 18:10:54 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-15.txt 
Originator-Info: login-token=Mulberry:01pxY8IhF+sZbzYbSj2pRskT6Ic00uSrUUi2qH3ZY=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, January 24, 2006 02:08:49 PM -0800 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

> However, I note that in regards to issue 2 in Tom's summary,
> I did not use Jeffrey's suggestion.

In the section in question, there was a concern that the text in -14 
implied that the authentication id was always contained directly in the 
client's credentials.  My concern was that in cleaning that up, we might 
lose the important concept that the server discovers the client's 
authentication id as a side-effect of the authentication exchange, and my 
suggested text was intended to provide one way to avoid that problem.

I agree that the changes you actually did make in this area both addressed 
the original issue and avoided the problem about which I was concerned.

-- Jeff

Date: Tue, 24 Jan 2006 14:08:49 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-rfc2222bis-15.txt 
Sender: [email-masked]

--=====================_10442846==_
Content-Type: text/plain; charset="us-ascii"

This revision is intended to address issues raised during the
most recent WG Last Call.

The changes made are mostly inline with Tom's summary of
WG Last Call issues.

However, I note that in regards to issue 2 in Tom's summary,
I did not use Jeffrey's suggestion.  This suggested text implied
the credentials carry an authentication identity which can be
extracted.  Using this text would have created an
inconsistency with the concept that the authentication identity
used in verifications may not which is the credentials, but
merely one "associated" with the credentials.  For instance,
when using SASL/PLAIN, the LDAP server may map the simple user
name to an LDAP DN and use this to fetch the stored value
used to verify the asserted password, and then upon success,
map the simple user name (or the LDAP DN) to a form appropriate
for making an proxy authorization decision, or if not proxying,
map the simple user name (or the LDAP DN) to a form appropriate
for making access control (authorization) decisions.  Instead,
I made a number of minor changes which I hope adequately
resolve this issue.  While I suggest those concerned in this
area review all of the relevant portions of the I-D (to ensure
the whole text is consistent), those interested in the particulars
can review the attached diff of my nroff.

I also note that I made no change in regards to issue 6 as the
current text "provides adequate warning about this problem",
including additional text in other places, especially
Section 3, would likely be distracting, and no specific suggestions
were offered.

With these changes, I believe the I-D is suitable for progression
to the IESG.  I ask Tom (who serves as sole WG chair in regards to
this I-D), after allowing adequate time for the WG to review the
changes, to determine if the WG supports such action and to take
appropriate action(s) based upon this determination. 

Kurt

--=====================_10442846==_
Content-Type: application/octet-stream; name="rfc2222bis.diff";
 x-mac-type="42494E41"; x-mac-creator="5843454C"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="rfc2222bis.diff"

--=====================_10442846==_--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-15.txt 
Date: Tue, 24 Jan 2006 15:50:02 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov, K. Zeilenga
	Filename	: draft-ietf-sasl-rfc2222bis-15.txt
	Pages		: 32
	Date		: 2006-1-24
	
The Simple Authentication and Security Layer (SASL) is a framework for
  providing authentication and data security services in
  connection-oriented protocols via replaceable mechanisms.  It 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 describes how a SASL mechanism is structured, describes
  how protocols include support for SASL, and defines the protocol for
  carrying a data security layer over a connection.  Additionally, this
  document defines one SASL mechanism, the EXTERNAL mechanism.

  This document obsoletes RFC 2222.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-15.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sasl-rfc2222bis-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-15.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-15.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-rfc2222bis-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 12 Jan 2006 08:47:34 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: GSSAPI/GS2 conclusions
Cc: [email-masked]
Sender: [email-masked]

At 01:01 PM 1/11/2006, Alexey Melnikov wrote:
>>2) There appears that there is little to no support for the
>>WG to produce a SPNEGO specification, and given that
>>no good reason has been established to take over
>>change control for this mechanism and no existing charter
>>support for this work, I conclude the WG should not continue
>>work in this area.
>Does this mean that I should remove section talking about SPNEGO?
>Can I keep/reword it as non-normative section?

Regardless of whether our to-be-revised charter contains a
work item to specify the SASL GSS-SPNEGO mechanism, I would
suggest SASL GSS-SPNEGO mechanism be specified separately for
the SASL GSSAPI mechanism specification so that security and other
considerations detailed for SASL GSS-SPNEGO won't so easily be
confused with the security and other considerations
detailed for SASL GSSAPI.  Additionaly, there differences
in usage (LIMITED v. COMMON) and possibly track (Standards
Track v. non-Standards Track (Info?)), seems to call for
separate I-Ds as well.

My recommendation is that you remove SPENGO from the GSSAPI
I-D and,
  A) if the revised charter doesn't contain a SPENGO work item,
  submit an SPENGO I-D on an individual basis, or
  B) if the revised charter does contain a SPENGO work time,
  submit an SPENGO I-D as a WG I-D.

As indicated in my comments, I don't see the revised charter
including a SASL SPNEGO work item, so I suggest A for now.

Kurt 

Date: Wed, 11 Jan 2006 21:01:59 +0000
From: Alexey Melnikov <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked]
Subject: Re: GSSAPI/GS2 conclusions
Sender: [email-masked]

Kurt D. Zeilenga wrote:

>My conclusions regarding GSSAPI/GS2 process issues are:
>
>1) While the interest in this "GSSAPI" mechanism appears (based
>upon number of reviewers) to be small, it seems there is
>sufficient interest to continue efforts in this area at least
>for now.  Hence I recommend this revising the GSSAPI mechanism
>specification remain a work item for the time.  However, I am
>concerned that the I-D hasn't gotten sufficient review.
>If this trend continues, our ability to deliver will be impeded.
>  
>
Agreed in both cases.

>2) There appears that there is little to no support for the
>WG to produce a SPNEGO specification, and given that
>no good reason has been established to take over
>change control for this mechanism and no existing charter
>support for this work, I conclude the WG should not continue
>work in this area.
>
Does this mean that I should remove section talking about SPNEGO? Can I 
keep/reword it as non-normative section?

>  Note: individuals with concerns
>regarding SPNEGO can provide IANA with registration
>comments (see RFC 2222).
>
>3) There appears to be sufficient support to use
>draft-josefsson-sasl-gs2 as a basis for a GSSAPI family
>of SASL mechanisms.  I recommend Simon continue as WG
>Editor submitting his next revision as draft-ietf-sasl-gs2.
>  
>
Agreed.

>The charter description and milestones should be modified
>to reflect the above.
>  
>

To: [email-masked]
Subject: WG Last Call Summary: Simple Authentication and Security Layer (SASL)
From: Tom Yu <[email-masked]>
Date: Mon, 09 Jan 2006 00:56:01 -0500
Lines: 163
Sender: [email-masked]

Only few issues appear to have arisen during Working Group Last Call.
Several of these issues can be resolved by fairly minimal edits.
Editors: please submit another draft resolving these issues.

After the draft resolving these issues is published, I will conclude
that the Working Group has reached consensus, and I will submit this
document to the IESG for consideration as a Proposed Standard.  Please
let me know if you have feedback concerning this course of action, or
about the issues identified below.

Issues (0), (1), and (2) are minor editorial issues which I feel are
not exceptionally contentious.  Issues (3), (4), and (5) involve
optional fields in the authentication request and the authentication
outcome message.  I believe that issue (3) is moderately complex, but
only requires a reasonably simple change.  Issue (6) is a potential
interoperability problem on which I would like opinions.

ISSUES
======

(0) The draft does not display its expiration date in explicit form;
    the Internet-Draft Guidelines state that the text "expires in six
    months" is not acceptable.

(1) Hallvard Furuseth notes that in Section 4, "authentication
    identity" appears to be erroneously written where "authorization
    identity" is meant in the following text:

> 4.  Protocol Requirements

>     Where the specification does not precisely prescribe how identities
>     in SASL relate to identities used elsewhere in the protocol, for
>     instance in access control policy statements, it may be appropriate
>     for the protocol to provide a facility by which the client can
>     discover information (such as the representation of the
>     authentication identity used in making access control decisions)
>     ^^^^^^^^^^^^^^^^^^^^^^^
>     about established identities for these uses.

    I believe the above change is reasonable, and that there is
    consensus to make this change.

(2) Discussion indicates that text describing credentials could be
    more explicit about the relationship of the authentication
    identity to the credentials.  Jeffrey Hutzelman's suggested text
    appears to be reasonable:

>>>>> "jhutz" == Jeffrey Hutzelman <[email-masked]> writes:

jhutz> OLD TEXT:
jhutz>   The server is responsible for verifying the client's credentials and
jhutz>   verifying that the client is allowed to act as the authorization
jhutz>   identity.  A SASL exchange fails if either (or both) of these
jhutz>   verifications fails.  (The SASL exchange may fail for other reasons,
jhutz>   such as service authorization failure.)

jhutz> NEW TEXT:
jhutz>   The server is responsible for verifying the client's credentials,
jhutz>   extracting the client's authentication identity (in a manner which
jhutz>   depends on the mechanism being used), and verifying that the client
jhutz>   is allowed to act as the requested authorization identity.  A SASL
jhutz>   exchange fails if either verification (or both) fails.  (The SASL
jhutz>   exchange may also fail for other reasons, such as service
jhutz>   authorization failure).

    I saw no objections to the above text.

(3) Hallvard notes a more complex issue involving some ambiguity in
    the definition "initial response" in the context of optional data
    provided in the application protocol's authentication request.  I
    agree with Hallvard that the usage in Section 5 is inconsistent
    with the usage elsewhere in the document, and that the intended
    usage of "initial response" is "first authentication data
    transmitted by the client".  I suggest the following changes:

> 5.  Mechanism Requirements

[...]

>   2) A definition of the server-challenges and client-responses of the
>      authentication exchange, as well as:

>      a) An indication whether mechanism is client-first, variable, or
>         server-first.  If a SASL mechanism is defined as client-first
>         and the client does not send an initial response, then the first

    Insert "in the authentication request" after "initial response".

>         server challenge MUST be empty (the EXTERNAL mechanism is an
>         example of this case).  If a SASL mechanism is defined as
>         variable, then the specification needs to state how the server
>         behaves when the initial client response is omitted (the

    Insert "from the authentication request" after "is omitted".

>         DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case).
>         If a SASL mechanism is defined as server-first then the client
>         MUST NOT send an initial client response (the CRAM-MD5 mechanism

    Insert "in the authentication request" after "initial client
    response".

>         [CRAM-MD5] is an example of this case).

(4) Discussion initiated by Hallvard suggests that text describing
    optional initial response (in the authentication request) or
    optional additional final data (in the authentication outcome)
    could use additional clarification.  My evaluation of the
    discussion suggests the following interpretations:

    (a) Within the authentication request, an application protocol may
        optionally support a field containing an initial client
        response.  It is optional for an implementation to actually
        send this initial client response field, but implementations
        of such an application protocol must accept this initial
        response field.

    (b) Within the authentication outcome message, an application
        protocol may optionally a field containing additional data
        from the server.  It is optional for an implementation to
        actually use this additional data field, but implementations
        of such an application protocol must accept this additional
        data field.

    I do not have specific recommended text to address this issue.

(5) Addressing a minor editorial issue brought up by Hallvard, I
    suggest (based on discussion) to change the following text in
    Section 3:

>   Where mechanisms specify the first data sent in the exchange is from
>   the client to the server and additional data is sent to the client
>   along with indicating a successful outcome, and the protocol provides
>   fields supporting both, the exchange can be shorted by two
>   round-trips:

    by replacing "the exchange ... round-trips:" with "then the
    exchange takes two fewer round trips:".

(6) I have found a potential interoperability problem.  In the course
    of my own review of the document, I noticed that Section 4
    requires that an application protocol providing a field for
    initial client response data in the authentication request must
    have a means for distinguishing an empty initial response from an
    absent initial response.  There is a similar requirement on the
    additional data field in the authentication outcome.

    I think this is a potential interoperability trap.  It seems to me
    that text as it stands probably provides adequate warning about
    this problem, but perhaps additional text emphasizing this
    requirement should appear in other places (e.g., Section 3)
    mentioning the optional initial response and additional data
    fields.  I would like additional opinions on this subject, but
    this issue may not be sufficiently serious to hold up the
    document.

==========

Again, please let me know if you have feedback about the results of
this Last Call.

 --- Tom Yu, SASL WG co-chair

Date: Tue, 03 Jan 2006 14:41:25 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: GSSAPI/GS2 conclusions
Sender: [email-masked]

My conclusions regarding GSSAPI/GS2 process issues are:

1) While the interest in this "GSSAPI" mechanism appears (based
upon number of reviewers) to be small, it seems there is
sufficient interest to continue efforts in this area at least
for now.  Hence I recommend this revising the GSSAPI mechanism
specification remain a work item for the time.  However, I am
concerned that the I-D hasn't gotten sufficient review.
If this trend continues, our ability to deliver will be impeded.

2) There appears that there is little to no support for the
WG to produce a SPNEGO specification, and given that
no good reason has been established to take over
change control for this mechanism and no existing charter
support for this work, I conclude the WG should not continue
work in this area.  Note: individuals with concerns
regarding SPNEGO can provide IANA with registration
comments (see RFC 2222).

3) There appears to be sufficient support to use
draft-josefsson-sasl-gs2 as a basis for a GSSAPI family
of SASL mechanisms.  I recommend Simon continue as WG
Editor submitting his next revision as draft-ietf-sasl-gs2.

The charter description and milestones should be modified
to reflect the above.

- Kurt, SASL co-chair