Subject: RFC 4616 on The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 31 Aug 2006 11:03:29 -0700
List-Id: <ietf-sasl.imc.org>

A new Request for Comments is now available in online RFC libraries.

        RFC 4616

        Title:      The PLAIN Simple Authentication and 
                    Security Layer (SASL) Mechanism 
        Author:     K. Zeilenga, Ed.
        Status:     Standards Track
        Date:       August 2006
        Mailbox:    [email-masked]
        Pages:      11
        Characters: 20270
        Updates:    RFC2595
        See-Also:   

        I-D Tag:    draft-ietf-sasl-plain-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4616.txt

This document defines a simple clear-text user/password Simple
Authentication and Security Layer (SASL) mechanism called the PLAIN
mechanism.  The PLAIN mechanism is intended to be used, in combination
with data confidentiality services provided by a lower layer, in
protocols that lack a simple password authentication command.  [STANDARDS 
TRACK]

This document is a product of the Simple Authentication and Security Layer
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Date: Thu, 31 Aug 2006 10:47:08 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: WG Last Call: draft-ietf-sasl-gs2-02.txt
Sender: [email-masked]

This message initiates a SASL Working Group Last Call on the
document:

  Title:     Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
  Editor:    S. Josefsson
  Filename:  draft-ietf-sasl-gs2-02.txt

The purpose of this WG Last Call is to ensure that the Working
Group has achieved consensus that the document is suitable for
publication on the Standards Track.

Please review the document for both technical and editorial
problems.  Technical issues should be discussed on this list.
Editorial issues may be sent to the document editor.  In
the case that a reviewer finds no technical issues, the
reviewer should send a note to the WG chairs indicating
so.

The Last Call period will close on Monday, 18 Sept. 2006.

Upon completion of the WG Last Call, the WG chair(s) will take
action based upon the consensus of the WG.  Possible actions
include:

  1) recommending to the IETF Security Area Directors
     that the document, after possible editorial or
     other minor changes, be considered by the IESG
     for publication as a Standard Track RFC; or

  2) requiring that outstanding issues be adequately
     addressed prior to further action (including,
     possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members
to ensure the quality of our documents.  So, please read and
comment!

Kurt Zeilenga, SASL WG co-chair 

Date: Thu, 31 Aug 2006 12:12:40 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Text (Re: Proposed updates for domain-based drafts)
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Proposed changes to draft-ietf-kitten-gssapi-domain-based-names-02.txt
below.

The changes amount to:

 - recast the purpose of domain-based names, namely: protecting
   applicationst that use insecure server discovery

 - clarify that the meaning of "domain" here is application specific

 - Provide non-normative examples

 - Add references

Comments?

 Abstract
 
    This document describes domainname-based service principal names and
    the corresponding name type for the Generic Security Service
    Application Programming Interface (GSS-API).
 
    Domain-based service names are similar to host-based service names,
    but using a domain name (not necessarily an Internet domain name)
    instead of or in addition to a hostname.  The primary purpose of
-   domain-based service names is to provide a way to name clustered
-   services after the domain which they service, thereby allowing their
-   clients to authorize the service's servers based on authentication of
-   their names.
+   domain-based names is to provide a measure of protection to
+   applications that utilize insecure service discovery protocols.  This
+   is achieved by providing a way to name clustered services after the
+   domain which they service, thereby allowing their clients to
+   authorize the service's servers based on authentication of their
+   service names.

 Table of Contents
 
    1.    Conventions used in this document  . . . . . . . . . . . . .  3
    2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.    Name Type OID and Symbolic Name  . . . . . . . . . . . . . .  5
    4.    Query and Display Syntaxes . . . . . . . . . . . . . . . . .  6
-   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   4.1.  Examples of domain-based names . . . . . . . . . . . . . . .  6
+   5.    Application protocol examples  . . . . . . . . . . . . . . .  7
+   5.1.  NFSv4 domain-wide namespace root server discovery  . . . . .  7
+   5.2.  LDAP server discovery  . . . . . . . . . . . . . . . . . . .  7
    6.    Security Considerations  . . . . . . . . . . . . . . . . . .  8
    7.    References . . . . . . . . . . . . . . . . . . . . . . . . .  9
    7.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . .  9
    7.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . .  9
          Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
          Intellectual Property and Copyright Statements . . . . . . . 11
 
[...]

 2.  Introduction
 
-   The use of hostbased principal names for domain-wide services
-   presents the problem of how to distinguish between an instance of a
-   hostbased service that is authorized to respond for a domain and one
-   that isn't.
+   Some applications need to discover the names of servers for a
+   specific resource.  Some common methods for server discovery are
+   insecure, e.g., queries for DNS [RFC1035] SRV resource records
+   [RFC2782] without using DNSSEC [RFC4033] and subject to attacks
+   whereby a client can be re-directed to incorrect and possibly
+   malicious servers.  A client may even be re-directed to a server that
+   has credentials for itself and may thus authenticate itself to the
+   client, and yet it could be incorrect or malicious (because it has
+   been compromised, say).
 
-   Consider LDAP.  LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V
-   mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased
-   principal with a service name of "ldap", a reasonable approach,
-   provided there is only one logical LDAP directory in a Kerberos
-   realm's domain, and that all ldap servers in that realm serve that
-   one LDAP directory.  An network might have multiple, distinct LDAP
-   services, but only one LDAP "name service"; if so then clients could
-   not tell which LDAP service principals are authorized to serve which
-   directory, not without assuming a secure method for finding LDAP
-   servers (e.g., DNSSEC).  This is a significant, and oft-unstated
-   restriction on users of LDAP.
+   Domain-based names allow for GSS-API [RFC2743] initiator applications
+   (clients) to authorize acceptor principals (servers) to serve the
+   resource for which the client used insecure server discovery without
+   either securing the server discovery method nor requiring an
+   additional protocol for server authorization -- either a discovered
+   server has credentials for authenticating the domain-based service
+   names that it is intended to respond to, or it does not.
+   Availability of valid credentials for authenticating domain-based
+   names embodies the authorization of a given server to a domain-wide
+   service.
 
-   Domain based names can eliminate this problem: the use of domain-
-   based names should imply that the given host is a server for the
-   official LDAP name service of the given domain.
-
-   Notwithstanding the LDAP example the use of domain-based principal
-   names for LDAP is not actually specified here and will be specified
-   in a separate document.
-
    A domain-based name consists of three required elements:
 
    o  a service name
 
    o  a domain name
 
    o  a hostname
 
+   For the purposes of domain-based names a "domain" is defined by the
+   applications that use domain-based names.  An application protocol
+   might use a simple DNS domainname, such as "example.com" for naming,
+   while another it might use the DNS domainname of the SRV RRs it
+   queries (e.g., "_tcp._foo.example.com"), and yet another may use
+   something that does not resemble a DNS domainname.  Application
+   protocol specifications that provide for use of domain-based service
+   names MUST define the domain-portion of their domain-based names.
 
[...] 

 4.  Query and Display Syntaxes
 
    There is a single name syntax for domain-based names.
 
    The syntax is:
 
       domain-based-name :=
 
-         | <service> '@' <domain> '@' <hostname>
+         <service> '@' <domain> '@' <hostname>
 
-   Note that for Internet domain names the trailing '.' is not and MUST
-   NOT be included in the domain name (or hostname) parts of the display
-   form GSS-API domain-based MNs.
+   Note that for Internet domain names the trailing '.'  MUST NOT be
+   included in the hostname part of the display form GSS-API domain-
+   based MNs; hostnames MUST NOT contain '@'.
 
+4.1.  Examples of domain-based names
 
+   These examples are not normative:
 
+   o  [email-masked]@ds1.example.tld
 
+   o  [email-masked]@nfsroot1.example.tld
 
-5.  Examples
+5.  Application protocol examples
 
-   o  [email-masked]@ds1.example.tld
+   The following examples are not normative.  They describe how the
+   author envisions two applications' use of domain-based names.
 
-   o  [email-masked]@kdc1.example.tld
+5.1.  NFSv4 domain-wide namespace root server discovery
 
+   Work is ongoing to provide a method for constructing domain-wide
+   NFSv4 [RFC3530] filesystem namespaces where there is a single "root"
+   with one or more servers (replicas) and multiple filesystems glued
+   into the namespace through use of "referrals."  Clients could then
+   construct a "global" namespace through use of the DNS domain
+   hierarchy.
 
+   Here clients would always know, from context, when they need to find
+   the root servers for a given DNS domain.  Root server discovery would
+   be performed using DNS SRV RR lookups, without using DNSSEC where
+   DNSSEC has not been deployed.
 
+   When using RPCSEC_GSS [RFC2203] for security NFSv4 clients would then
+   use domain-based names to ensure that that the servers named in the
+   SRV RRs are in fact authorized to be the NFSv4 root servers for the
+   target domain.
 
+5.2.  LDAP server discovery
 
+   LDAP clients using the GSS-API through SASL too would benefit from
+   use of domain-based names to protect server discovery through
+   insecure DNS SRV RR lookups, much as described above.
 
+   Unlike NFSv4 clients, not all LDAP clients may always know from
+   context when they should use domain-based names.  That's because
+   existing clients may use host-based naming to authenticate servers
+   discovered through SRV RR lookups.  Changing such clients to use
+   domain-based naming when domain-based acceptor credentials have not
+   been deployed to LDAP servers, or when LDAP servers have not been
+   modified to allow use of domain-based naming, would break
+   interoperability.  That is, there is a legacy server interoperability
+   issue here.  Therefore LDAP clients may require additional
+   configuration at deployment time to enable (or disable) use of
+   domain-based naming.
 
+   Note: whether SASL [RFC4422] or its GSS-API bridges [I-D.ietf-sasl-
+   gssapi] [I-D.josefsson-sasl-gs2] require updates in order allow use
+   of domain-based names is not relevant to the theory of how domain-
+   based naming would protect LDAP clients' server discovery.
 
 6.  Security Considerations
 
    Use of GSS-API domain-based names may not be negotiable by some GSS-
    API mechanisms, and some acceptors may not support GSS-API domain-
    based names.  In such cases initiators are left to fallback on the
    use of hostbased names, in which case the initiators MUST also verify
    that the acceptor's hostbased name is authorized to provide the given
    service for the domain that the initiator had wanted.
 
    The above security consideration also applies to all GSS-API
    initiators who lack support for domain-based service names.

[...]

 7.1.  Normative
 
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [RFC2743]  Linn, J., "Generic Security Service Application Program
               Interface Version 2, Update 1", RFC 2743, January 2000.
 
-7.2.  Informative
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000.
 
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
 
-   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
-              (SASL)", RFC 2222, October 1997.
+7.2.  Informative
 
-   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
-              Protocol (v3): Technical Specification", RFC 3377,
-              September 2002.
+   [I-D.ietf-sasl-gssapi]
+              Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism",
+              draft-ietf-sasl-gssapi-06 (work in progress), June 2006.
 
+   [I-D.josefsson-sasl-gs2]
+              Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2
+              Mechanism Family", draft-josefsson-sasl-gs2-00 (work in
+              progress), November 2005.
 
+   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
+              Specification", RFC 2203, September 1997.
 
+   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
+              Beame, C., Eisler, M., and D. Noveck, "Network File System
+              (NFS) version 4 Protocol", RFC 3530, April 2003.
 
+   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
+              Security Layer (SASL)", RFC 4422, June 2006.

Date: Thu, 31 Aug 2006 11:53:45 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked], Mark Crispin <[email-masked]>, [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to	Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01SqiUhLQQCfiW8wwFfSbE8+Eay6/R3A23HcLpgCg=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, August 30, 2006 06:26:22 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Wed, Aug 30, 2006 at 06:51:56PM -0400, Sam Hartman wrote:
>> I think the best you can do is:
>>
>> Therefore, RFC 2222 implementations will not work with GSS
>> implementations that require integ_req_flag to be true.  No
>> implementations of RFC 1964 or RFC 4121 that require integ_req_flag to
>> be true are believed to exist and it is expected that any future
>> update to RFC 4121 will require that integrity be available even in
>> not explicitly requested by the application.
>
> I will not object to this text.  I do not think it necessary.

I concur.

Date: Wed, 30 Aug 2006 16:29:00 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Nicolas Williams <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

If this the best that can be done, then please do it.  Thanks.

On Wed, 30 Aug 2006, Sam Hartman wrote:
> I think the best you can do is:
>
> Therefore, RFC 2222 implementations will not work with GSS
> implementations that require integ_req_flag to be true.  No
> implementations of RFC 1964 or RFC 4121 that require integ_req_flag to
> be true are believed to exist and it is expected that any future
> update to RFC 4121 will require that integrity be available even in
> not explicitly requested by the application.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 30 Aug 2006 18:26:22 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Sam Hartman <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 06:51:56PM -0400, Sam Hartman wrote:
> I think the best you can do is:
> 
> Therefore, RFC 2222 implementations will not work with GSS
> implementations that require integ_req_flag to be true.  No
> implementations of RFC 1964 or RFC 4121 that require integ_req_flag to
> be true are believed to exist and it is expected that any future
> update to RFC 4121 will require that integrity be available even in
> not explicitly requested by the application.

I will not object to this text.  I do not think it necessary.

I would also not object to adding a reference to the compatibility note
in RFC2743, section 2.2.1 -- think of mechglue's that too could require
the caller set these flags in order to be able to use the corresponding
per-message token services.

I believe that the compatibility note in RFC2743, section 2.2.1, is
clear that implementations which enforce the incompatible change must
distinguish between GSS-API v1 and v2 callers.  I believe therefore that
no compliant GSS-API implementation, mechglue or mechanism, can break
RFC2222 SASL/GS1 implementations.  That makes this whole thing a
non-issue.

Nico
-- 

Date: Wed, 30 Aug 2006 18:06:47 -0500
From: Nicolas Williams <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Philip Guenther <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 04:32:32PM -0600, Philip Guenther wrote:
> I don't think anyone is worried about Sun getting this particular issue 
> wrong, mainly because there's someone there (you) who knows the GSSAPI and 
> SASL oral history and who is keeping an eye on things.

That's not why!  It's because you can file bugs and someone at Sun
(note: not I) would either know, or interface with someone else who
knows (e.g., everyoone here) directly or indirectly (i.e., read this
entirely-too-long thread in the mail archive, probably through a search
engine).

Folks, RFC2743 is clear about this change: v2u1 implementations that
require these flags must detect v1 callers -- requiring the flags is
optional, and the only way for C bindings implementations to detect
callers' expectation is to use library versioning.  Plus, no implementor
wants to require said flags.

Thus this is much ado about nothing.

From: Sam Hartman <[email-masked]>
To: Philip Guenther <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 19:05:20 -0400
Sender: [email-masked]

It's fairly clear that the document needs to stand alone.

However we're not discussing a gss document here.  We're discussing a
sasl document here.  The reason this SASL document requires the flag
be set is that it guarantees that it will work with gssapi 2.1
implementations.  This document normatively requires gssapi 2.1 so
that's sufficient.

Several people have pointed out to Mark that RFC 4121 could be updated
to require integrity even when the flag is not set and pointed to
ongoing work that could be used to accomplish that goal.

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 18:51:56 -0400
Sender: [email-masked]

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> RFC 2222 did not have the requirement, added in this
    Mark> revision, that integ_req_flag be set by the caller to
    Mark> GSS_Init_sec_context().  There is no means by which GSSAPI
    Mark> can know that the caller complies with RFC 2222 or with this
    Mark> update.
    Mark> Therefore, the language on page 47 of RFC 2743 is to be
    Mark> interpreted as indicating that a GSSAPI (Kerberos v5) SASL
    Mark> mechanism caller to GSS_Init_sec_context() that does not set
    Mark> integ_req_flag complies with RFC 2222 and not with this
    Mark> revision.  To maintain interoperability, the GSSAPI layer
    Mark> SHOULD infer integ_req_flag as set, as described on page 47
    Mark> of RFC 2743.

Both of these requirements attempt to place normative changes on gss
mechanisms; that's inappropriate for this document.

I think the best you can do is:

Therefore, RFC 2222 implementations will not work with GSS
implementations that require integ_req_flag to be true.  No
implementations of RFC 1964 or RFC 4121 that require integ_req_flag to
be true are believed to exist and it is expected that any future
update to RFC 4121 will require that integrity be available even in
not explicitly requested by the application.

Date: Wed, 30 Aug 2006 16:32:32 -0600
From: Philip Guenther <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Nicolas Williams wrote:
...
> My point is that the particular bug you are concerned about would very
> likely be considered a bug by Sun (oh, I personally can't guarantee even
> that much, that's true also).

Nico,

I don't think anyone is worried about Sun getting this particular issue 
wrong, mainly because there's someone there (you) who knows the GSSAPI and 
SASL oral history and who is keeping an eye on things.

The problem is that the IETF is a bit schizo about how 'standalone' 
documents need to be.  I have seen it claimed that the requirements for 
advancing to draft or full standard mean that it should be possible to 
create an interoperable implementation of the standard by reading the RFC 
and its dependencies WITHOUT consulting mailing list archives or dragging 
oral history out of people.

Now, I don't believe that's true for many of the standard marked as such. 
The exchange on this issue in draft-ietf-sasl-gssapi has involved dozens 
of messages and ground down to "well, no one who knows the history would 
do that", so it's not true of this document plus GSSAPIv2.1 either.

While consistent, that position leaves the meaning of IETF standards in 
the hands of the lists and not fixed by the documents.  The fact that that 
position is not, as far as I can tell, backed up by RFC 2026, means that 
you will lose or have a much harder time winning arguments over protocol 
details with people who disagree with the mailing list but that follow the 
strict wording of the RFC.  "The document and not the list is the only 
thing that matters.  You can't change the document just by saying so on 
the list: you have to publish a revision...and now that you bring it up 
I'll fight that because I don't want to change my implementation!"

So, when some IETF newbie does an implementation of GSSAPI v2.1 that 
breaks Mark's GSSAPIv2 application, is there an authoritative statement 
somewhere that Mark can point to that says
 	"no really: if you implemented the kerberos5 mech for version 2.1
 	 of the GSS API, then you needed to have consulted the ietf-sasl
 	 mailing list archive to find that integrity must be supported
 	 regardless of the setting of that flag."

If not, is there a more general IETF process statement about the authority 
of mailing lists?

Philip Guenther

Date: Wed, 30 Aug 2006 15:54:16 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism'	to	Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Simon Josefsson <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Sender: [email-masked]

On Wed, Aug 30, 2006 at 10:35:11PM +0200, Simon Josefsson wrote:
> > Would that not be a valid response by implementors who did not version
> > their GSS libraries, that they will change the major version number only
> > when they make backwards-incompatible changes?
> 
> That question seem to assumes that changing the major version number
> of the GSS-API library would be noticed by anyone.  I don't think this
> is the case in practice.  I don't know any programmatic way to
> discover the major library version nor the GSS-API revision from the
> GSS-API library that I use in my SASL library.  Is there one?  The
> situation is complicated because I typically only ship source code.

If you dynamically link against one version of a library and that
version is replaced by a new major version something very noticeable
should happen.

Of course we're in the realm of platform-specific details.  I'm done
with this thread.  I'm not sure what else can be said of any value that
could affect the consensus.

For the record: I believe no changes are needed to this I-D with regards
to integ_req_flag.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 30 Aug 2006 22:37:36 +0200
Sender: [email-masked]

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>
>     Simon> Adding an implementation note to explain the situation
>     Simon> seems like the best solution to me.
>
> I'm happy with a non-normative implementation note.  I've proposed
> text which has received a luke-warm reception.

I think your text is OK.  It may be tweaked further, but I don't have
any concrete suggestions.  The point is to make the reader aware that
there is a potential problem here.  I don't think anyone will think of
checking the GSS-API revision of the GSS-API library they use
otherwise.

/Simon

From: Simon Josefsson <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>, [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to	Proposed Standard (draft-ietf-sasl-gssapi)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 30 Aug 2006 22:35:11 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Aug 30, 2006 at 06:41:07PM +0200, Simon Josefsson wrote:
>> None of the GSS-API libraries I've worked with provides library
>> versioning that corresponds to the GSS-API revision.  Several Kerberos
>> GSS-API mechanisms (including MIT's) support the integ_req flag
>> without implementing all of GSS-API v2u1, or even all of v2.  The
>> versioning of GSS-API is not consistently visible at the API level.
>
> Is this because they've never made backwards-incompatible changes, such
> as requiring use of integ_req_flag in order to get integrity protection?

Yes, perhaps.

> Would that not be a valid response by implementors who did not version
> their GSS libraries, that they will change the major version number only
> when they make backwards-incompatible changes?

That question seem to assumes that changing the major version number
of the GSS-API library would be noticed by anyone.  I don't think this
is the case in practice.  I don't know any programmatic way to
discover the major library version nor the GSS-API revision from the
GSS-API library that I use in my SASL library.  Is there one?  The
situation is complicated because I typically only ship source code.

What would be useful for application writers would be to check which
GSS-API revision a particular GSS-API library implements, preferably
both at build-time (for C, perhaps a CPP symbol) and during run-time
(a new API).

/Simon

Date: Wed, 30 Aug 2006 15:04:50 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I suppose I should clarify that vendors, Sun included, don't always fix
all bugs.

My point is that the particular bug you are concerned about would very
likely be considered a bug by Sun (oh, I personally can't guarantee even
that much, that's true also).

Nico
-- 

Date: Wed, 30 Aug 2006 14:31:20 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 12:24:14PM -0700, Mark Crispin wrote:
> On Wed, 30 Aug 2006, Nicolas Williams wrote:
> >If so then the only reasonable conclusion is that integ_req_flag ==
> >FALSE MUST NOT imply that integrity protection is not available.
> 
> So how would this be stated in the document?

It doesn't have to be.

Nico
-- 

From: Martin Rex <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
To: [email-masked] (Nicolas Williams)
Date: Wed, 30 Aug 2006 21:30:50 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> > GSSAPI violates this; V2 specifically states that it does not make 
> > backward-incompatible changes.
> 
> If so then the only reasonable conclusion is that integ_req_flag ==
> FALSE MUST NOT imply that integrity protection is not available.

YES!  I tried to say this in so many ways.

> 
> Can we stop now?

Yes, please.

-Martin

Date: Wed, 30 Aug 2006 12:24:14 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Nicolas Williams wrote:
> If so then the only reasonable conclusion is that integ_req_flag ==
> FALSE MUST NOT imply that integrity protection is not available.

So how would this be stated in the document?

Application:	integ_req_flag MUST be set

K5 GSSAPI/SASL:	integ_req_flag is implied set, regardless of whether or
 		not it was set by the application

 	Something like:

Implementation note:

RFC 2222 did not have the requirement, added in this revision, that 
integ_req_flag be set by the caller to GSS_Init_sec_context().  There is 
no means by which GSSAPI can know that the caller complies with RFC 2222 
or with this update.

Therefore, and notwithstanding the language on page 47 of RFC 2743, a 
GSSAPI implementation MUST imply that integ_req_flag is set when used for 
the GSSAPI (Kerberos v5) SASL mechanism.

 	or perhaps (weaker, but alright):

Implementation note:

RFC 2222 did not have the requirement, added in this revision, that 
integ_req_flag be set by the caller to GSS_Init_sec_context().

Therefore, the language on page 47 of RFC 2743 is to be interpreted as 
indicating that a GSSAPI (Kerberos v5) SASL mechanism caller to 
GSS_Init_sec_context() that does not set integ_req_flag complies with RFC 
2222 and not with this revision.  To maintain interoperability, the GSSAPI 
layer SHOULD infer integ_req_flag as set, as described on page 47 of RFC 
2743.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 14:22:13 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 12:07:49PM -0700, Mark Crispin wrote:
> On Wed, 30 Aug 2006, Nicolas Williams wrote:
> >Marc, the reality is that vendors try hard to avoid customer complaints
> >about backwards incompatibility by avoiding breaking backwards
> >compatibility in the first place.
> 
> This is all fine and good, but the reality is that they don't always 
> succeed.  SUN is not immune.  Nor do all vendors make such commitments.

We can't guarantee that we won't break anything -- bugs happen.  But we
provide support, and support means fixing bugs when they happen.  And
what we consider a bug as a lot to do with commitment to interface
stability.

This is getting silly.  Either you accept vendor commitments and hold us
to them or you don't, but if you do and the commitment is there then
please stop arguing "but you might break it accidentally!" -- yes, we
might, but that's not a useful argument here.  And if you don't accept
these commitments then you have no case anyways because nothing we do
here can possibly make you happy.

Nico
-- 

Date: Wed, 30 Aug 2006 14:08:41 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Note too: I don't speak for MIT.  As for Sun's commitment to stability,
see attributes(5).

Nico
-- 

Date: Wed, 30 Aug 2006 12:07:49 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Nicolas Williams wrote:
> Marc, the reality is that vendors try hard to avoid customer complaints
> about backwards incompatibility by avoiding breaking backwards
> compatibility in the first place.

This is all fine and good, but the reality is that they don't always 
succeed.  SUN is not immune.  Nor do all vendors make such commitments.

We live in an imperfect world.  Good faith doesn't always exist, and those 
of good faith sometimes blunder.  Nor do vendors do a particularly good 
job of taking responsibility/blame even when it is their fault.

My 30-odd year collection of horror stories is best suited for discussion 
at a bar, over large (and continuously refilled) pitchers of beer.

If we can prevent this particular problem from being added to the 
collection, we should.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 13:56:44 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 11:48:21AM -0700, Mark Crispin wrote:
> On Wed, 30 Aug 2006, Nicolas Williams wrote:
> >Is this because they've never made backwards-incompatible changes, such
> >as requiring use of integ_req_flag in order to get integrity protection?
> 
> I don't know.  Do you?

See my other reply just now about vendor commitments to interface
stability.

> >Would that not be a valid response by implementors who did not version
> >their GSS libraries, that they will change the major version number only
> >when they make backwards-incompatible changes?
> 
> GSSAPI violates this; V2 specifically states that it does not make 
> backward-incompatible changes.

If so then the only reasonable conclusion is that integ_req_flag ==
FALSE MUST NOT imply that integrity protection is not available.

Can we stop now?

Nico
-- 

Date: Wed, 30 Aug 2006 13:55:17 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 11:35:57AM -0700, Mark Crispin wrote:
> On Wed, 30 Aug 2006, Nicolas Williams wrote:
> >See my response to Simon's message.  Basically, I would consider the
> >lack of major number changes in any implementor's GSS-API libraries as
> >indication of commitment to not having made backwards-incompatible
> >changes.
> 
> I agree with the sentiment.  Nonetheless, to date, vendors (including 
> SUN!) have not made such commitments and repeatedly shy away from making 
> any such commitment.

Absolutely we have.  MIT is committed to a number of things, such as ABI
backwards compatibility for all their public MIT krb5 interfaces
(including the GSS C bindings).

Sun is also strongly committed to backwards compatibility for Stable
(Committed) interfaces, and when appropriate we consider behaviour to be
an interface.

We would not make backwards-incompatible changes to libgss without
bumping the library version number, and we wouldn't deprecate old
versions of it without at least a year's warning before the minor
release where they would be deprecated.

Marc, the reality is that vendors try hard to avoid customer complaints
about backwards incompatibility by avoiding breaking backwards
compatibility in the first place.

If Sun broke libgss and/or mech_krb5 so that not setting
GSS_C_INTEG_FLAG leads to gss_get/verify_mic() and/or gss_wrap/unwrap()
failing, then I'd expect: a) customers to complain and high-priority
bugs to be filed, b) Sun to fix those bugs.

I'm pretty sure that MIT would make/makes the same commitment.  The only
difference being: the set of interfaces to which they commit, their
release taxonomy and schedules, and amount of warning they give for
obsolescence.  But you might not be using MIT directly, but another
vendor (or Linux distro) that bundles MIT, and they may make additional
commitments (e.g., Solaris uses MIT source code, but our commitments are
somewhat stronger than MIT's).

Nico
-- 

Date: Wed, 30 Aug 2006 11:48:21 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Nicolas Williams wrote:
> Is this because they've never made backwards-incompatible changes, such
> as requiring use of integ_req_flag in order to get integrity protection?

I don't know.  Do you?

> Would that not be a valid response by implementors who did not version
> their GSS libraries, that they will change the major version number only
> when they make backwards-incompatible changes?

GSSAPI violates this; V2 specifically states that it does not make 
backward-incompatible changes.

Perhaps you meant that backwards-incompatible changes are made only when 
the major version number is change.  If so, GSSAPI violates this as well; 
the change was made between V2 and V2.1, not (as falsely claimed by RFC 
2743) between V1 and V2.

How does notification work for a change in major version number?  In 
particular, what change is made to GSSAPI, so that someone who does a 
"make" of an application that picks up the wrong version of GSSAPI gets an 
error, and consequently is obliged to make some edit to the application to 
comply with the new version of GSSAPI?

Which standards document (not necessarily IETF) mandates all this? 
Vendors have a long history of being quite careless on this point, and I 
would love to have a standard to fling at the next violator.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 11:35:57 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Nicolas Williams wrote:
> See my response to Simon's message.  Basically, I would consider the
> lack of major number changes in any implementor's GSS-API libraries as
> indication of commitment to not having made backwards-incompatible
> changes.

I agree with the sentiment.  Nonetheless, to date, vendors (including 
SUN!) have not made such commitments and repeatedly shy away from making 
any such commitment.

We do not live in an ideal world; and (to paraphrase Simon) it is not 
realistic nor constructive to point out that the problem does not exist in 
an ideal world.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

From: Martin Rex <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
To: [email-masked] (Nicolas Williams)
Date: Wed, 30 Aug 2006 19:59:41 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> Implementors of C bindings of the GSS-API (RFC2744) should do library
> versioning to prevent this problem.  Similarly for other language
> bindings of the GSS-API.

I violently disagree. ;-)

The (first) SPNEGO document (rfc-2478) predates rfc-2743/44,
Appendix B of the C-Bindings (rfc-2744) makes explict recommendations
for binary plug'n'play, and already RFC-1508 has the notion of
"applications portable accross different mechanisms".

While it is perfectly OK for a particular gssapi mechanism
to be hardwired to a particular application with esoteric,
non-portable or plain stupid features, it is definitely against
the spirit and design goals of the GSS-API spec.

Portable applications, as well as protocol specs that are not
intended to be hardwired to only a particular gssapi mechanism
should be conservative ("portable" in the GSS-API sense) in their
requirements and be prepared to meet any one from a number of
possible gssapi mechanisms at runtime.  SPNEGO does not require
that all mechanisms that it negotiates have the same maturity
levels, it may be a mixture of old v1 and brand-new v2u1 mechanisms.

-Martin

Date: Wed, 30 Aug 2006 12:57:23 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 01:18:07PM -0400, Sam Hartman wrote:
>     Jeffrey> I suspect we can resolve this with a blanket statement
>     Jeffrey> about what to do when any GSS-API call returns
>     Jeffrey> major_status other than GSS_S_COMPLETE or (during context
>     Jeffrey> establishment) GSS_S_CONTINUE_NEEDED.
> 
> I prefer this approach as it deals with gap tokens and replay tokens
> in the security layer negotiation and authorization identity exchange
> as well.

Me too.  Also, note that SASL/GS1 requires setting the out-of-sequence
detection flag but SASL being stream oriented this means that to get
replay protection the caller has to check for the OOS status codes and
abort the security layer/SASL session when tokens are delivered out of
order or replayed.

Date: Wed, 30 Aug 2006 12:39:16 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 10:20:00AM -0700, Mark Crispin wrote:
> On Wed, 30 Aug 2006, Nicolas Williams wrote:
> >Did you link statically?  If so, there's no issue.
> 
> I don't know.  It depends upon how the system provider set up links to the 
> GSSAPI library.
> 
> >Did you link dynamically?
> 
> I don't know.  It depends upon how the system provider set up links to the 
> GSSAPI library.
> 
> >If so, did the library version change?
> 
> I don't know.  I have no way of knowing.
> 
> Please refer to Simon's message.

See my response to Simon's message.  Basically, I would consider the
lack of major number changes in any implementor's GSS-API libraries as
indication of commitment to not having made backwards-incompatible
changes.  Or at least that's what I think *you*, as a customer/user
should demand of your vendors.

> >And the implementor is still acting in good faith by not breaking 
> >backwards compatibility.
> 
> I'm confused.  What entity is offering surety that this is, and will 
> remain, the case?

The implementor.

Date: Wed, 30 Aug 2006 12:36:54 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>, [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to	Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Simon Josefsson <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>, [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Sender: [email-masked]

On Wed, Aug 30, 2006 at 06:41:07PM +0200, Simon Josefsson wrote:
> None of the GSS-API libraries I've worked with provides library
> versioning that corresponds to the GSS-API revision.  Several Kerberos
> GSS-API mechanisms (including MIT's) support the integ_req flag
> without implementing all of GSS-API v2u1, or even all of v2.  The
> versioning of GSS-API is not consistently visible at the API level.

Is this because they've never made backwards-incompatible changes, such
as requiring use of integ_req_flag in order to get integrity protection?

Would that not be a valid response by implementors who did not version
their GSS libraries, that they will change the major version number only
when they make backwards-incompatible changes?

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 13:27:03 -0400
Sender: [email-masked]

To make it painfully clear what my position is:

I care very littel about code compatibility: I think it is entirely
reasonable for the IETF to publish a new spec that requires you to
write code to comply with and that your existing code does not comply
with.  I think that we need to have a reason for doing so but that the
bar is rather low.  I suspect we disagree strongly about this point.

I care a great deal about wire compatibility.  I think it is a big
problem when we change a protocol in such a way that a new client
cannot work with an old server or in which a old client cannot work
with a new server.  Sometimes we need to do that; generally we use
versioning mechanisms or new protocols when we do.

I have seen no claim that the wire protocol described in RFC 2222
differs from the wire protocol described in this draft.  Thus I think
we have met our primary compatibility objective.

I agree with you and Jeff that the way in which integ_req flag was
introduced into RFC 2743 may be ill-considered.

I agree with you that it would be appropriate to update the Kerberos V
mechanism to require integrity be available all the time.  I disagree
that this spec should block on such an update.

--Sam

Date: Wed, 30 Aug 2006 13:26:10 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01OMSFmKIs+gyED/0Za0K1B882vMO/+P6lObP9bkQ=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, August 30, 2006 01:18:07 PM -0400 Sam Hartman 
<[email-masked]> wrote:

>>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>
>     Jeffrey> I don't think we need to check for replay protection and
>     Jeffrey> sequencing.  I think we do need to check for availability
>     Jeffrey> of integrity protection, because even without a security
>     Jeffrey> layer, the basic security of this mechanism depends on
>     Jeffrey> GSS_Wrap, and as Martin points out, RFC 2743 does not
>     Jeffrey> specify what happens if you call GSS_Wrap when integrity
>     Jeffrey> protection is not available.
>
> The MUSt in 4422 is that you use integrity protection if the
> underlying mechanism supports it.  I don't understand how you can get
> into a situation where you don't have it with Kerberos, but if you do,
> it seems acceptable to move on without it.

Hm, so it is.  In which case, I guess we can get by without checking 
integ_avail in the general case, as long as we don't end up in a situation 
where we are claiming to be providing a security layer with integrity or 
confidentiality when we actually are not.

-- Jeff

Date: Wed, 30 Aug 2006 13:24:21 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01UTKolLuaHQidfSAVhLDYA+ik37/YZiG+p9b5h7I=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, August 30, 2006 01:14:19 PM -0400 Sam Hartman 
<[email-masked]> wrote:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>
>     Simon> Adding an implementation note to explain the situation
>     Simon> seems like the best solution to me.
>
> I'm happy with a non-normative implementation note.  I've proposed
> text which has received a luke-warm reception.

If I recall correctly, Mark found your text acceptable, and so did I.
However, I believe Mark thought more was needed.

Unfortunately, I'm having trouble understanding what, beyond your text, 
Mark would like us to do _in this document_.

Mark, can you spell out exactly what further change you'd like to see to 
draft-ietf-sasl-gssapi-07.txt, beyond Sam's proposed text?  I know you've 
probably said already, but I'd like to cut through some of the weeds here 
to give Sam and the chairs a clear picture of what dispute remains, if any, 
that needs to be addressed before this document can move forward.

-- Jeff

Date: Wed, 30 Aug 2006 10:20:00 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Nicolas Williams wrote:
> Did you link statically?  If so, there's no issue.

I don't know.  It depends upon how the system provider set up links to the 
GSSAPI library.

> Did you link dynamically?

I don't know.  It depends upon how the system provider set up links to the 
GSSAPI library.

> If so, did the library version change?

I don't know.  I have no way of knowing.

Please refer to Simon's message.

> If
> not, did the implementor break apps that don't set the integ_req_flag?

I don't know.  I have no way of knowing.

> Has the implementor not assured you that they wouldn't do that in a
> future release?

I don't know who the implementor is, much less have talked with him or her 
to get such assurances.

> C library versioning is non-standard.

Yes.

> And the implementor is still acting in good faith by not breaking 
> backwards compatibility.

I'm confused.  What entity is offering surety that this is, and will 
remain, the case?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 13:18:07 -0400
Sender: [email-masked]

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

    Jeffrey> I don't think we need to check for replay protection and
    Jeffrey> sequencing.  I think we do need to check for availability
    Jeffrey> of integrity protection, because even without a security
    Jeffrey> layer, the basic security of this mechanism depends on
    Jeffrey> GSS_Wrap, and as Martin points out, RFC 2743 does not
    Jeffrey> specify what happens if you call GSS_Wrap when integrity
    Jeffrey> protection is not available.

The MUSt in 4422 is that you use integrity protection if the
underlying mechanism supports it.  I don't understand how you can get
into a situation where you don't have it with Kerberos, but if you do,
it seems acceptable to move on without it.

    Jeffrey> In general, I think this specification does a poor job of
    Jeffrey> specifying what happens when various GSS-API operations
    Jeffrey> return errors.  In general, I would hope that
    Jeffrey> implementors would be good about checking for errors
    Jeffrey> returned by functions they call, but experience has
    Jeffrey> taught me that such hope is often in vain.

    Jeffrey> I suspect we can resolve this with a blanket statement
    Jeffrey> about what to do when any GSS-API call returns
    Jeffrey> major_status other than GSS_S_COMPLETE or (during context
    Jeffrey> establishment) GSS_S_CONTINUE_NEEDED.

I prefer this approach as it deals with gap tokens and replay tokens
in the security layer negotiation and authorization identity exchange
as well.

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 13:14:19 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Adding an implementation note to explain the situation
    Simon> seems like the best solution to me.

I'm happy with a non-normative implementation note.  I've proposed
text which has received a luke-warm reception.

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 13:12:47 -0400
Sender: [email-masked]

Mark, I think we're going in circles here.

Question to the world at large: is anyone else still confused about
this or believe we're taking the wrong approach?

Date: Wed, 30 Aug 2006 11:44:19 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 09:19:40AM -0700, Mark Crispin wrote:
> On Wed, 30 Aug 2006, Nicolas Williams wrote:
> >Implementors of C bindings of the GSS-API (RFC2744) should do library
> >versioning to prevent this problem.  Similarly for other language
> >bindings of the GSS-API.
> 
> I agree.  But they didn't do that.
> 
> >Therefore this should not be a possible outcome.  If it is then it is
> >because either: a) you screwed up, and/or b) your GSS-API implementor
> >screwed up.
> 
> (b) has happened.  They probably did not realize that there would be a 
> problem; they thought that all they had to do was substitute their new 
> bits and all the old software would continue to work.

Did you link statically?  If so, there's no issue.

Did you link dynamically?  If so, did the library version change?  If
not, did the implementor break apps that don't set the integ_req_flag?
Has the implementor not assured you that they wouldn't do that in a
future release?

> They probably acted in good faith.  After all, the GSSAPI specification 
> goes to length to talk about backwards compatibility except for this one 
> wart.

C library versioning is non-standard.

And the implementor is still acting in good faith by not breaking
backwards compatibility.

Nico
-- 

Date: Wed, 30 Aug 2006 09:42:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Sam Hartman wrote:
> Interoperability.  If you set the flag, your code will work against
> existing and past acceptors.  If you do not set the flag, your code
> may end up failing against some acceptors.

What created this interoperability problem?

Did it exist in 1994, when RFC 1731 was written?

Did it exist in 1997, when RFC 2222 was written?

Did it exist in 1998, when my code was written?

Did it exist in 2000, when RFC 2743 was written?

Does it exist today, prior to the publication of draft-ietf-sasl-gssapi?

I think that we all agree that when draft-ietf-sasl-gssapi is published, 
the problem will exist.  As matters stand, if the problem exists, it is a 
specification bug: RFC 2222 is the standard for the GSSAPI SASL mechanism, 
and RFC 2743 created an interoperability problem.

I understand that draft-ietf-sasl-gssapi intends to fix the problem by 
establishing a requirement for new implementations.  All fine and good. 
But it doesn't fix the problem for the implementations out there.

"Document and depreciate" is an acceptable solution for old software.

>    Mark> Do we need to abandon the GSSAPI SASL mechanism in favor of
>    Mark> the GSSAPIrev1 SASL mechanism?
> I think not because we're talking about the same wire protocol.

Doesn't that presuppose that the interoperability problem is only 
theoretical in nature?

If so, why not declare the theory mandatory for the specific scope of K5 
in the GSSAPI SASL mechanism?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

From: Simon Josefsson <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 30 Aug 2006 18:41:07 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Aug 29, 2006 at 07:47:10PM -0700, Mark Crispin wrote:
>> On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
>> >As soon as you compiled and linked your code against a library that 
>> >implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant 
>> >with RFC 2222.
>> 
>> That is not an acceptable outcome.
>
> Implementors of C bindings of the GSS-API (RFC2744) should do library
> versioning to prevent this problem.  Similarly for other language
> bindings of the GSS-API.
>
> Therefore this should not be a possible outcome.  If it is then it is
> because either: a) you screwed up, and/or b) your GSS-API implementor
> screwed up.
>
> We cannot prevent implementor/deployer mistakes.  We might warn about
> ones that we can imagine and which we think are likely, but we can't
> imagine all possible implementor/deployer mistakes.

None of the GSS-API libraries I've worked with provides library
versioning that corresponds to the GSS-API revision.  Several Kerberos
GSS-API mechanisms (including MIT's) support the integ_req flag
without implementing all of GSS-API v2u1, or even all of v2.  The
versioning of GSS-API is not consistently visible at the API level.

In practice, it is difficult to tell which GSS-API version a
particular implementation supports (e.g., MIT supports some but not
all of v2u1).  So I don't think the above is a realistic or
constructive way to look at this.

While I agree with Sam that keeping the recommendation of asserting
the integ_req flag is the right thing, I agree with Mark that we
should look at the deployed based here, and be careful to not
invalidate old implementations.  Whether RFC 2222 reference RFC 2078
or RFC 2743 is an academic aspect -- the important aspect is what
happens with the programs that are, and will be, deployed.

Adding an implementation note to explain the situation seems like the
best solution to me.

/Simon

Date: Wed, 30 Aug 2006 09:31:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Sam Hartman wrote:
> We don't know.  We know that the behavior is well-defined if you set
> the integ_req flag.  RFC 1964 and 4121 fairly strongly imply that
> integrity service is always available but don't actually say so.

Well, we've identified a work item for somebody, haven't we?

> It would be really stupid to implement a Kerberos GSS-API mechanism
> that made integrity service optionally available.  Several people from
> the Kerberos community including myself have come forward and said
> they have never run into such a mechanism.

If this discussion was taking place 20 years ago, the word of a recognized 
authority (such as Sam Hartman) that "this isn't a problem" would be 
enough for me.

Unfortunately, I have experienced too many episodes since then in which I 
trusted the word of a recognized authority -- and understood the issue 
myself! -- only to have it blow up in my face years later at the hands of 
someone who refuses to recognize the authority (or the mailing list 
archive!), insists that only the specification is normative, and that 
given an ambiguity the interpretation that harms my implementation is the 
correct one.

The worst part about it is that such individuals are correct.  The 
recognized authority and mailing list archive are not normative; only the 
specification is normative.  And if the specification allows leeway then 
you don't have a leg to stand on when you complain about it.

I think that this discussion has gone long enough that it can't be swept 
under the rug.  The problem needs to be tackled.  It is of little 
consequence to me precisely how it is tackled, as long as it is tackled. 
And no, "it's your fault for building with the wrong version of the 
library" does not constitute tackling the problem.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 30 Aug 2006 12:25:57 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, [email-masked]
cc: [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01hXbXH+/eTJPRwU+guPQHjhzoDkoMqlDy6wWEu/Y=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, August 30, 2006 12:14:04 PM -0400 Sam Hartman 
<[email-masked]> wrote:

> However the text in 3.3 needs to make it clear that gap_token or
> replay_token are a fatal error from gss_unwrap for this mechanism.
>
> Without this, the security layer is subject to replay attacks or
> reordering.  Jeff Hutzelman may argue that we should check that the
> context negotiated actually provides replay protection and integrity
> protection.  I don't think so. If the implementation does not actually
> support that, I think it is still acceptable to choose whatever
> security layer we can.

I don't think we need to check for replay protection and sequencing.
I think we do need to check for availability of integrity protection, 
because even without a security layer, the basic security of this mechanism 
depends on GSS_Wrap, and as Martin points out, RFC 2743 does not specify 
what happens if you call GSS_Wrap when integrity protection is not 
available.

In general, I think this specification does a poor job of specifying what 
happens when various GSS-API operations return errors.  In general, I would 
hope that implementors would be good about checking for errors returned by 
functions they call, but experience has taught me that such hope is often 
in vain.

I suspect we can resolve this with a blanket statement about what to do 
when any GSS-API call returns major_status other than GSS_S_COMPLETE or 
(during context establishment) GSS_S_CONTINUE_NEEDED.

-- Jeff

Date: Wed, 30 Aug 2006 09:19:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Nicolas Williams wrote:
> Implementors of C bindings of the GSS-API (RFC2744) should do library
> versioning to prevent this problem.  Similarly for other language
> bindings of the GSS-API.

I agree.  But they didn't do that.

> Therefore this should not be a possible outcome.  If it is then it is
> because either: a) you screwed up, and/or b) your GSS-API implementor
> screwed up.

(b) has happened.  They probably did not realize that there would be a 
problem; they thought that all they had to do was substitute their new 
bits and all the old software would continue to work.

They probably acted in good faith.  After all, the GSSAPI specification 
goes to length to talk about backwards compatibility except for this one 
wart.

I acted in good faith too; and most certainly I did not "screw up" by 
not knowing, in 1998, about a change made in 2000.

> We cannot prevent implementor/deployer mistakes.  We might warn about
> ones that we can imagine and which we think are likely, but we can't
> imagine all possible implementor/deployer mistakes.

That is all true.  Nonetheless, you can (and should!) deal with a problem 
which has now been identified.

> I think you're making a tempest in a teapot.

Were you aware that RFC 822 allowed your email address to be:
  Nicolas (as in the saint) . Williams @ sun (not moon) . (not org) com
in headers?  Does your MUA handle it?  Some do, many do not!

The concensus of all the network experts 25 or so years ago was that 
nobody would actually be crazy enough to do such a thing.  RFC 2822 
specifically forbids it today, because it became a tempest in a teapot 
(and a rather nasty one).

After a few experiences like this, you learn not to disregard tempests in 
teapots.  It may not always be possible to anticipate, and thus prevent, 
one from popping up.  But once once does, you deal with it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 12:14:04 -0400
Sender: [email-masked]

It's with great trepidation that I send this message, but I seem to
have found another area where draft-ietf-sasl-gssapi is missing
mandatory requirements.

There is a security problem in the definition of security layers in
section 3.3.

The text correctly requires that callers to gss_init_sec_context
request replay protection and sequencing if they are going to
negotiate a security layer.

However the text in 3.3 needs to make it clear that gap_token or
replay_token are a fatal error from gss_unwrap for this mechanism.

Without this, the security layer is subject to replay attacks or
reordering.  Jeff Hutzelman may argue that we should check that the
context negotiated actually provides replay protection and integrity
protection.  I don't think so. If the implementation does not actually
support that, I think it is still acceptable to choose whatever
security layer we can.

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 12:00:52 -0400
Sender: [email-masked]

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> On Wed, 30 Aug 2006, Sam Hartman wrote: It is most certainly
    Mark> a requirement that a protocol specification update not break
    Mark> compliant implementations written to an earlier
    Mark> specification.
    >> Speaking as an AD, the above is not a requirement of the IETF
    >> process.  It is a very good idea unless other concerns
    >> override.

    Mark> Is there an overriding concern?  If so, what is it?

Interoperability.  If you set the flag, your code will work against
existing and past acceptors.  If you do not set the flag, your code
may end up failing against some acceptors.

    Mark> If an incompatibility must be introduced, there is a
    Mark> versioning mechanism that enables the new stuff only between
    Mark> consenting implementations.
    >> Again, a very good idea.

    Mark> I'm glad that you agree.

    Mark> Do we need to abandon the GSSAPI SASL mechanism in favor of
    Mark> the GSSAPIrev1 SASL mechanism?

I think not because we're talking about the same wire protocol.

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 11:58:46 -0400
Sender: [email-masked]

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> On Wed, 30 Aug 2006, Sam Hartman wrote:
    >> Statements about what GSS-API mechanisms should or should not
    >> do do not belong in a SASL document.

    Mark> This document specifically discusses the Kerberos V5 GSSAPI

We don't know.  We know that the behavior is well-defined if you set
the integ_req flag.  RFC 1964 and 4121 fairly strongly imply that
integrity service is always available but don't actually say so.

It would be really stupid to implement a Kerberos GSS-API mechanism
that made integrity service optionally available.  Several people from
the Kerberos community including myself have come forward and said
they have never run into such a mechanism.

--Sam

Date: Wed, 30 Aug 2006 10:43:22 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
Mail-Followup-To: Martin Rex <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 04:55:50PM +0200, Martin Rex wrote:
> In my reading, RFC-2743 does not contain a MUST either, only a recommendation
> in non-normative words, which amounts to a SHOULD.

RFC2743 does not use RFC2119 terminology at all.  Just what RFC2743
requires, recommends or allows is sometimes a matter of interpretation.

Nico
-- 

Date: Wed, 30 Aug 2006 10:40:59 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
Mail-Followup-To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wed, Aug 30, 2006 at 05:04:46PM +0200, Martin Rex wrote:
> GSS-API is a child of DCE, and DCE originally intended to provide
> an integrity-only Kerberos for export (due to US crypto export regulation).

Did DCE ever ship like that?  If so then that would make two
implementations that did :)

> However, the availability of confidentiality protection wasn't
> a result of the initiator not requesting confidentiality protection
> (how could it -- these flags weren't available in GSS-API v1).

Also, the implementation simply didn't have the confidentiality
protection protection code, so even with those flags it could not
provide it.

> It was supposed to be a (lack of)feature of a particular implementation,
> and intended to go smooth on the application.

I think it is non-smooth, but whatever.

> As I said, however, absence of message integrity is un(der)specified.

Something to clarify.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
Date: Wed, 30 Aug 2006 11:32:48 -0400
Sender: [email-masked]

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> If the mechanism does not need additional round trips, and
    Martin> if the mechanism has previously been doing it correctly,
    Martin> then I think such a backwards incompatible change would be
    Martin> not only "poor design", but also non-conforming.

I don't see the argument that this is non-conforming.  I do completely
agree with you about the motivation of the flags and about the
problems caused by such a mechanism.  I also agree that the IETF would
not standardize such a mechanism.

I have no problem updating RFC 2743 to say that either this should be
(or is) non-conforming.  I just don't think today's text says that
clearly enough.

I don't think such an update should block the SASL document.

Thanks for your information on the motivation of these flags.

--Sam

Date: Wed, 30 Aug 2006 10:29:08 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 29, 2006 at 07:47:10PM -0700, Mark Crispin wrote:
> On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
> >As soon as you compiled and linked your code against a library that 
> >implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant 
> >with RFC 2222.
> 
> That is not an acceptable outcome.

Implementors of C bindings of the GSS-API (RFC2744) should do library
versioning to prevent this problem.  Similarly for other language
bindings of the GSS-API.

Therefore this should not be a possible outcome.  If it is then it is
because either: a) you screwed up, and/or b) your GSS-API implementor
screwed up.

We cannot prevent implementor/deployer mistakes.  We might warn about
ones that we can imagine and which we think are likely, but we can't
imagine all possible implementor/deployer mistakes.

I think you're making a tempest in a teapot.

Nico
-- 

From: Martin Rex <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
To: [email-masked] (Nicolas Williams)
Date: Wed, 30 Aug 2006 17:04:46 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Nicolas Williams wrote:
> 
> (At least one implementation of the Kerberos V GSS mechanism used to
> leave out confidentiality protection, but none, to my knowledge, fails
> to provide MIC and/or wrap tokens when integ_req_flag == false in the
> call to GSS_Init_sec_context().)

GSS-API is a child of DCE, and DCE originally intended to provide
an integrity-only Kerberos for export (due to US crypto export regulation).

However, the availability of confidentiality protection wasn't
a result of the initiator not requesting confidentiality protection
(how could it -- these flags weren't available in GSS-API v1).
It was supposed to be a (lack of)feature of a particular implementation,
and intended to go smooth on the application.

As I said, however, absence of message integrity is un(der)specified.

-Martin

From: Martin Rex <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
To: [email-masked] (Mark Crispin)
Date: Wed, 30 Aug 2006 16:55:50 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Mark Crispin wrote:
> 
> I request consideration of the following changes prior to publication.
> 
> Page 4, first paragraph, please change:
>     [...]  When calling the GSS_Init_sec_context the client
>     MUST pass the integ_req_flag of TRUE.
> to
>     [...]  When calling the GSS_Init_sec_context the client
>     SHOULD pass the integ_req_flag of TRUE.
 
In my reading, RFC-2743 does not contain a MUST either, only a recommendation
in non-normative words, which amounts to a SHOULD.

> 
> Suggested changes (this is just cosmetic):
> 
> Page 5, second paragraph, change
>     [...] chan_binding of NULL
> to:
>     [...] chan_binding of GSS_C_NO_CHANNEL_BINDINGS

For several GSS-API calls explicit text was added to specify
what (kind of default) behaviour should occur if a empty/NULL
value was supplied as certain input parameters.

For this purpose, several additional symbolic constants were added.
John Wray probably added the constants for all of the types in the
header file, but the NO_CHANNEL_BINDINGS never made it into the
high level spec because it wasn't discussed (channel bindings
were a rarely used feature, which is why so few gssapi mechanisms
implement them).

The use of a GSS_C_NO_* symbol instead of NULL was *not* meant to
allow other values, just to give them a more readable name.

-Martin

From: Martin Rex <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
To: [email-masked] (Sam Hartman)
Date: Wed, 30 Aug 2006 16:16:19 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Sam Hartman wrote:
> 
>     Martin> A gssapi mechanism that implements message protection
>     Martin> services but refuses them if the newly added
>     Martin> "conf_req_flag" and "integ_req_flag" weren't passed in
>     Martin> during gss_init_sec_context() must be considered seriously
>     Martin> broken.
> 
> Do you believe such a mechanism violates a normative requirement of RFC 2743?
> If so, which requirement (textual citation appreciated)?

The reason for the change was really only the negotiating mechanisms.

There is no requirement for application to assert conf_req_flag
or integ_req_flag as a prerequisite to use these services.
It was not in rfc2078 and rfc1508, and it is not in rfc2443.

   The conf_req_flag and integ_req_flag provide informatory inputs to
   the GSS-API implementation as to
                                     whether, respectively, per-message
   confidentiality and per-message integrity services will be required
   on the context.  This information is important as an input to
   negotiating mechanisms.
                            It is important to recognize, however, that
   the inclusion of these flags (which are newly defined for GSS-V2)
   introduces a backward incompatibility with callers implemented to
   GSS-V1, where the flags were not defined.

The reason why a negotiation mechanism might need the initiator to
assert these flags is so that it can remove all mechanisms from
the negotiation that do not fulfil this requirement, so that
it will not happen that the server (who has the privilege to select)
can not select a mechanism which does not fulfil the requirements
of the initiator.

However, the absence of a requirement on the side of the initiator
does *NOT* imply that the initiator does not want to use message
protection services!  All of the "request flags" for context attributes
are _options_ at the discretion of the caller (initiator).

> 
> Or are you saying that such a mechanism would be poorly designed? If
> the ladder, I completely agree.  If the former, I'm not finding the
> text, but that doesn't mean it isn't there.

If the mechanism does not need additional round trips, and if the
mechanism has previously been doing it correctly, then I think
such a backwards incompatible change would be not only "poor design",
but also non-conforming.

The paragraph in rfc-2743 carries an explicit "backwards incompatibility"
warning label, and it is sufficiently inconsistent/unclear that it
can not be used as an excuse for just about every conceivable misbehaviour.

Back then, many of the participants of CAT mostly cared about those
scenarios that they were using or envisioning themselves, and as I
said, the absence of integrity protection services didn't exist
until late into GSS-API v2 (in spite of the context attribute integ_avail).

You'll realize that when trying to figure out what gss_wrap()/gss_unwrap()
is supposed to do when integrity protection is not available.  It's not
really specified.

In order to facilitate application design, someone proposed that gss_wrap()
and gss_unwrap() should be a no-op when integrity protection is not available,
i.e. passing out what was passed in.  However, the total absense of
framing would break the GSS-API architecture.  Zero-length tokens
(context-length and message protection) are alien to GSS-API.
Zero-length application data is OK and explicitly mentioned in GSS-API v2;
it is used by secure FTP. 

I picked on a lot of areas of both documents in those areas that
I felt weren't sufficiently clear for the scenarios that I was
interested in.  Interestingly, my code had been asserting the
conf_req and integ_req flags from the beginning (in 1995),
I wasn't actually aware that these flags had NOT been input parameters
in GSS-API v1.  MIT Kerberos never had a problem with this and
C-Bindings say that unrecognized context request flags must be
ignored by a mechanism.

-Martin

Date: Tue, 29 Aug 2006 23:21:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Jeffrey Hutzelman wrote:
> Acceptable or not, it's what happens.  RFC 2222 makes reference to RFC 2078; 
> using another version is noncompliant.
>
> If you prefer, you can think of your source code as complying with RFC 2222 
> and RFC 2078, and of RFC 2078 and RFC 2743 being incompatible with each other 
> in such a way that your 2078-user might break when linked against a 
> 2743-provider.  The effect is the same.

That's not acceptable.

It is not valid to presume that someone building software has the 
slightest clue about the nature of the GSSAPI library.  Without that 
presumption it is not possible to declare differential behavior based upon 
having such a clue.

> You seem to be suggesting that someone somewhere should produce a document 
> which changes the behavior of existing implementations of that mechanism 
> which do not already behave as described above.

No.

I am suggesting that if (as is repeatedly claimed) all GSSAPI 
implementations infer the integ flag for the Kerberos V5 mechanism AND 
that it is "poorly designed" (as Sam and Martin have stated) for an 
implementation to do otherwise, that some document state that GSSAPI 
implementations SHOULD infer the integ flag for the Kerberos V5 mechanism.

It is not unheard-of for the IETF to produce documents that say something 
to the effect that "such-and-such is a good idea, so do it; however, 
such-and-such other thing is a bad idea, so don't do it."

These documents are called Implementation Recommendations, and they move 
matters of this from folklore and "well-known expert Mr. Jones says that 
this is the way to do it" into RFCs that can be referred to when a 
question comes up.

I don't understand why you are so opposed to doing this; especially since 
there is a real interoperability problem otherwise.  We are supposed to 
solve problems, not block others from obtaining a resolution to their 
problems.

Problem:	Tens of thousands of copies of software implemented in
 		good faith according to RFC 2222 are in the field.  If
 		some fool produces an RFC 2743 implementation that, as
 		Sam says is "poorly designed", the RFC 2222 software will
 		break with no changed to that software.

 		The implementor of the RFC 2222 software has already made
 		the necessary change to the next version, but that doesn't
 		help all the copies that are out in the field.

Proposed Solution:
 		Produce some document advising RFC 2743 implementors of
 		the problem with RFC 2222 implementors, and that they
 		SHOULD infer integ (the way all other known GSSAPI
 		implementations do) in Kerberos V5 to avoid the problem.

If you don't like my proposed solution, then come up with one which solves 
the problem equally well.  Something that does not involve crystal balls 
or forcing some poor schmuck who does a "make" to figure out which 
100-page RFC applies to the libraries installed on his system.

> I also don't see a change to the GSS-API, Version 2 imposing those 
> requirements on all mechanisms, partly because the "bit on the wire" in 
> question is specific to the Kerberos mechanism and partly because not all 
> mechanisms support integrity service at all.

I never said anything about "all mechanisms".  The document is an update 
to RFC 2222 for the GSSAPI SASL mechanism, which is specific to Kerberos 
V5.  What mechanisms other than Kerberos V5 mechanisms do is of no 
consequence to RFC 2222 implementations.

It may be of consequence to other applications and specifications which 
are affected by this incompatible change to GSSAPI, but that isn't my 
problem to solve; nor is it a problem for the RFC 2222 replacement.

This document replaces RFC 2222, and the problem in question directly 
affects implementors of the protocol in question.  This document solves 
the problem for new implementations, but not for the existing 
implementations in the field.  The latter needs to be solved.

> You could propose an update to the Kerberos GSS-API mechanism which makes 
> those recommendations.  The appropriate place to do so would be in the 
> Kerberos working group, which is currently working on a (minor) update to 
> that mechanism.

That may be, but in that case this document ("The Kerberos V5 SASL 
mechanism) should be blocked pending action by the Kerberos WG on this 
question.  Otherwise, that precludes the possibility of the Kerberos WG 
bouncing some portion of the problem back.

> Good, we agree on that.  This document is for new implementations.
> It can't very well tell old implementations what to do.

Nonetheless, it needs to concern itself with interoperability with old 
implementations.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Tue, 29 Aug 2006 22:44:17 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Sam Hartman wrote:
>    Mark> It is most certainly a requirement that a protocol
>    Mark> specification update not break compliant implementations
>    Mark> written to an earlier specification.
> Speaking as an AD, the above is not a requirement of the IETF process.
> It is a very good idea unless other concerns override.

Is there an overriding concern?  If so, what is it?

>    Mark> If an incompatibility
>    Mark> must be introduced, there is a versioning mechanism that
>    Mark> enables the new stuff only between consenting
>    Mark> implementations.
> Again, a very good idea.

I'm glad that you agree.

Do we need to abandon the GSSAPI SASL mechanism in favor of the GSSAPIrev1 
SASL mechanism?

We have testimony that the bits on the wire are the same.

We have testimony that all known GSSAPI implementations infer, at least in 
the case of Kerberos V5.

Nonetheless, it is *very* frightening to be told that working RFC 2222 
code may suddenly break, and that it's all the fault of the guy who gives 
a "make" command without first determining what version of the GSSAPI 
library is installed and reading the entire GSSAPI RFC for that version of 
the library.

[And if I was the sort of clown who didn't read RFCs, I wouldn't have 
picked up on that obscure point during Last Call, much less raised all 
this fuss!]

Can we avoid that scenario?  We have as a given that the old code won't 
change, otherwise it becomes new code that doesn't have the issue.

Is there something in new code that can be done to say "you don't need to 
infer with me", and state that code that fails to do that thing is old 
code and therefore must get auto-infer?

Can we simply issue an Informational RFC of GSSAPI Implementation 
Recommendations that says "not implying integ with K5 breaks RFC 2222 
implementations, so don't do it"?  Being Informational, it's non-normative 
and requires minimal review.  However, it would still be helpful should 
someone does what you yourself say would be "badly-designed".  It'll fully 
satisfy my concerns.

I believe that the WG, or even as an individual submission, can reasonably 
do such an Informational RFC.  I volunteer to write it if you'll give the 
OK.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Tue, 29 Aug 2006 22:24:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

On Wed, 30 Aug 2006, Sam Hartman wrote:
> Statements about what GSS-API mechanisms should or should not do do
> not belong in a SASL document.

This document specifically discusses the Kerberos V5 GSSAPI mechanism and 
no other GSSAPI mechanism.  Does that assist describing what happens vis a 
vis the integ_req_flag?

> If you can phrase something in terms of a recommendation for SASL
> implementations complying with this spec (not with RFC 2222), we can
> look at it.

My previous message to you offered a strawman, in the presumption that the 
integ_req_flag is not technically necessary today, but is made mandatory 
for some other reason (whether cosmetic or to allow for the extension of 
the GSSAPI SASL for other GSSAPI mechanisms besides Kerberos V5).

I don't know if the presumption is correct though.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Tue, 29 Aug 2006 22:20:50 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
Sender: [email-masked]

On Wed, 30 Aug 2006, Sam Hartman wrote:
> Do you believe such a mechanism violates a normative requirement of RFC 2743?
> If so, which requirement (textual citation appreciated)?

Upon reading RFC 2743, it's difficult to say.  Parts of the document imply 
a concern for backwards compatibility, but then there's this text on page 
47:
    [...] It is important to recognize, however, that
    the inclusion of these flags (which are newly defined for GSS-V2)
    introduces a backward incompatibility with callers implemented to
    GSS-V1, where the flags were not defined.  Since no GSS-V1 callers
    would set these flags, even if per-message services are desired,
    GSS-V2 mechanism implementations which enable such services
    selectively based on the flags' values may fail to provide them to
    contexts established for GSS-V1 callers.

That's the problem statement.  It then goes on to say:

    [...]  It may be appropriate under
    certain circumstances, therefore, for such mechanism implementations
    to infer these service request flags to be set if a caller is known
    to be implemented to GSS-V1.

What's stunningly absent here are any IETF normative qualifier words such 
as MUST [NOT], SHOULD [NOT], MAY, etc.  In reading this, I really don't 
know what, precisely, this means.  I don't know how this passed review 
with such ambiguous wording, but it did; so we have to guess what it all 
means.

What makes this all more complicated is the fact that the document being 
considered is "The Kerberos V5 (GSSAPI) SASL mechanism".  Throughout this, 
I have presumed that this means that the "mechanism implementation" is 
also Kerberos V5; and that therefore within the context of this document 
we can discount all other mechanism implementations.

Is Kerberos V5 a mechanism implementation that "enable[s per-message] 
services selectively based upon the flags' value"?

If so, is it "appropriate" for Kerberos V5 to infer these service request 
flags to be set?  How does GSSAPI know that the caller is implemented to 
GSS-V1?

If not (the Kerberos V5 mechanism implementation always enables these 
services), isn't the flag redundant?

Is the inclusion of the flag is not because it is necessary, but rather to 
provide a growth path for the GSSAPI SASL mechanism to support future 
mechanism implementations other than Kerberos V5?  If so, this can be 
stated with wording such as:
 	The Kerberos V5 mechanism implementation always infers the
 	integ_req_flag.  However, to provide for future extensibility,
 	GSSAPI SASL implementations that comply with this specification
 	MUST explicitly set the integ_req_flag.

The first sentence makes Mark Crispin happy.  The second sentence 
establishes the new requirement and makes everybody else.  Everybody is 
happy, we all go home.

> Or are you saying that such a mechanism would be poorly designed?  If
> the ladder, I completely agree.  If the former, I'm not finding the
> text, but that doesn't mean it isn't there.

I guess the question is if there is a meaningful implementation of the 
Kerberos V5 mechanism implementation that does not infer integ_req_flag 
(given that there is testimoney that one currently does not exist).

If there isn't, why not say so.  In such a case, I don't see why this 
document can not modify RFC 2743.  If that isn't palatable, I believe that 
whatever WG is current can create an implementation recommendations 
document for GSSAPI that simply says "The Kerberos V5 implementation 
mechanism should always infer integ_req_flag".

If, on the other hand, it is meaningful to implement the Kerberos V5 
implementation mechanism that way, saying that such an implementation is 
"poorly designed" doesn't help.  Since no such implementation currently 
exists, once again I don't see why there can't be a quick Informative RFC 
produced as a "GSSAPI Implementation Recommendations" to head it off.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 01:12:55 -0400
Sender: [email-masked]

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> It is most certainly a requirement that a protocol
    Mark> specification update not break compliant implementations
    Mark> written to an earlier specification. 

Speaking as an AD, the above is not a requirement of the IETF process.
It is a very good idea unless other concerns override.

    Mark> If an incompatibility
    Mark> must be introduced, there is a versioning mechanism that
    Mark> enables the new stuff only between consenting
    Mark> implementations.

Again, a very good idea.

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Wed, 30 Aug 2006 00:55:51 -0400
Sender: [email-masked]

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> On Tue, 29 Aug 2006, Jeffrey Altman wrote:
    >> does the text proposed by Sam Hartman meet your needs?

    Mark> It helps.  Could some part of what Martin Rex wrote also be
    Mark> incorporated?

Statements about what GSS-API mechanisms should or should not do do
not belong in a SASL document.

If you can phrase something in terms of a recommendation for SASL
implementations complying with this spec (not with RFC 2222), we can
look at it.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked] (Jeffrey Hutzelman), [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
Date: Wed, 30 Aug 2006 00:50:09 -0400
Sender: [email-masked]

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> A gssapi mechanism that implements message protection
    Martin> services but refuses them if the newly added
    Martin> "conf_req_flag" and "integ_req_flag" weren't passed in
    Martin> during gss_init_sec_context() must be considered seriously
    Martin> broken.

Do you believe such a mechanism violates a normative requirement of RFC 2743?
If so, which requirement (textual citation appreciated)?

Or are you saying that such a mechanism would be poorly designed?  If
the ladder, I completely agree.  If the former, I'm not finding the
text, but that doesn't mean it isn't there.

Date: Wed, 30 Aug 2006 00:33:08 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01d2jXpeHQTBnDs08mquYHFA7aDtD+nFDk3QUKreg=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, August 29, 2006 07:47:10 PM -0700 Mark Crispin 
<[email-masked]> wrote:

> On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
>> As soon as you compiled and linked your code against a library that
>> implementated RFC 2743/2744 instead of RFC 2078, it ceased to be
>> compliant  with RFC 2222.
>
> That is not an acceptable outcome.

Acceptable or not, it's what happens.  RFC 2222 makes reference to RFC 
2078; using another version is noncompliant.

If you prefer, you can think of your source code as complying with RFC 2222 
and RFC 2078, and of RFC 2078 and RFC 2743 being incompatible with each 
other in such a way that your 2078-user might break when linked against a 
2743-provider.  The effect is the same.

>> And compliant implementations of the new draft, using RFC4422 and
>> RFC2743,  will also work, provided the requirement we are talking about
>> is met.  If we  removed the requirement, then "compliant"
>> implementations that fail to meet  it might still fail to interoperate.
>> Again, that's unlikely, but only  because the present document is
>> restricted to the Kerberos mechanism.
>
> That's what the GSSAPI mechanism

Huh?  Looks like something got cut out here.

>> It is _not_ a requirement, and never has been, that a new protocol
>> specification be written such that older implementations be compliant
>> with  the new spec.  That would be silly, as it would essentially
>> prevent the  introduction of new features.
>
> It is most certainly a requirement that a protocol specification update
> not break compliant implementations written to an earlier specification.
> If an incompatibility must be introduced, there is a versioning mechanism
> that enables the new stuff only between consenting implementations.

What do you mean by "break" here?
We _are_ talking about the SASL GSSAPI mechanism, right?
There is nothing in draft-ietf-sasl-gssapi-07.txt that breaks 
implementations of the SASL GSSAPI mechanism as defined in RFC 2222 7.2.

> You have said that merely recompiling the software against a GSSAPI
> library that happens to be v2.1 will break software written before v2.1
> exists -- and with NO notification to the person doing the recompilation.

Actually, I've said it _may_ break that software, but probably won't.  Not 
because I think that's a good way for things to be, but because that's the 
way things _are_.  I'm confused as to what change you think should be made 
to draft-ietf-sasl-gssapi-07.txt to change this.

We seem to agree that the CAT working group made a mistake back in 1999 or 
so when RFC 2743 was written.  In fact, we seem to be in violent agreement 
on that point.  Can we stop wasting time on it?

In fact, I'm going to try to prune any threads which are merely 
reexpressions of how much you hate the backward-incompatible change or how 
wrong it was or how I must be making all sorts of ludicrous assumptions 
when I tell you that the API has changed and there's nothing we can do 
about it.

>> (a) the library you are using probably sets the bit on the wire even if
>>   you don't request it

>> (b) the library you are using implements GSS_Wrap correctly, including
>>   producing tokens with correct integrity checks, even if you didn't
>>   request integrity service (if this were not true, you'd already be
>>   seeing serious interop problems)

>> (c) the chance that any acceptor you talk to will fail to implement
>>   GSS_Unwrap correctly even if the bit was not set on the wire is
>>   vanishingly small(*)

So, these are predictions I made about your software, based on the 
assumption that it is probably compiled against one of a small number of 
widely-deployed implementations of the Kerberos GSS-API mechanism which 
happen to have these behaviors (actually, (c) is not a prediction about 
your software, but about software yours is likely to talk to).

You seem to be suggesting that someone somewhere should produce a document 
which changes the behavior of existing implementations of that mechanism 
which do not already behave as described above.  I don't see that 
happening.  I also don't see a change to the GSS-API, Version 2 imposing 
those requirements on all mechanisms, partly because the "bit on the wire" 
in question is specific to the Kerberos mechanism and partly because not 
all mechanisms support integrity service at all.

You could propose an update to the Kerberos GSS-API mechanism which makes 
those recommendations.  The appropriate place to do so would be in the 
Kerberos working group, which is currently working on a (minor) update to 
that mechanism.  This change isn't really in scope for that update, but if 
you can convince the working group to accept it, I don't think there will 
be a problem (note: the responsible AD might overrule me here, but I don't 
think he will).

>> Nonetheless, you've said several times that you shouldn't need to
>> understand  the internals of GSS-API.  To a certain extent, I agree with
>> that sentiment,  which is why things like the need to set integ_req_flag
>> need to be spelled  out in the SASL GSSAPI mechanism specification.
>> Otherwise, someone's going to  miss it.
>
> Needs to be spelled out for new implementations.

Good, we agree on that.  This document is for new implementations.
It can't very well tell old implementations what to do.

-- Jeff

Date: Tue, 29 Aug 2006 19:47:10 -0700
From: Mark Crispin <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
> As soon as you compiled and linked your code against a library that 
> implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant 
> with RFC 2222.

That is not an acceptable outcome.

> And compliant implementations of the new draft, using RFC4422 and RFC2743, 
> will also work, provided the requirement we are talking about is met.  If we 
> removed the requirement, then "compliant" implementations that fail to meet 
> it might still fail to interoperate.  Again, that's unlikely, but only 
> because the present document is restricted to the Kerberos mechanism.

That's what the GSSAPI mechanism

> Do you seriously think anyone is going to fault your RFC2222 implementation 
> for not being compliant with the new specification?  I doubt it.

If it suddenly breaks, they will.  That's what happens when software 
breaks.

And should that happen, I will not have kind things to say about the 
people involved with GSSAPI.

> It is _not_ a requirement, and never has been, that a new protocol 
> specification be written such that older implementations be compliant with 
> the new spec.  That would be silly, as it would essentially prevent the 
> introduction of new features.

It is most certainly a requirement that a protocol specification update 
not break compliant implementations written to an earlier specification. 
If an incompatibility must be introduced, there is a versioning mechanism 
that enables the new stuff only between consenting implementations.

> What is and has been at least strongly desired, if not actually required, is 
> that a new protocol specification be written such that compliant 
> implementations of the old version will interoperate with compliant 
> implementations of the new version.  I believe we have done that here.

No you have not.

You have said that merely recompiling the software against a GSSAPI 
library that happens to be v2.1 will break software written before v2.1 
exists -- and with NO notification to the person doing the recompilation.

That ain't interoperability.

>> I read RFC 2078.  Cover to cover.  I am starting to get angry.
> I'm sorry; I misspoke, and probably more than once.  What I meant to say was 
> that you apparently did not read RFC2743 before starting to use a newer 
> GSSAPI library based on it.

I recompile my implementation.  How the hell am I supposed to know what 
RFC the GSSAPI library is based upon?  I didn't install GSSAPI.

How the hell is anyone building my software supposed to know what RFC the 
GSSAPI library is based upon?

It is idiotic to require that someone doing a "make" command must read 
some set of obtuse RFCs first, on the possibility that some OTHER software 
changed unbeknownst to that person.

> And chances are that even if you did, you _still_ have nothing to worry 
> about, because
> (a) the library you are using probably sets the bit on the wire even if
>   you don't request it

Then make that "probably" into a SHOULD, due to the compatibility issue.

> (b) the library you are using implements GSS_Wrap correctly, including
>   producing tokens with correct integrity checks, even if you didn't
>   request integrity service (if this were not true, you'd already be
>   seeing serious interop problems)

Another SHOULD that is currently missing and needs to be there due to the 
compatibility issue.

> (c) the chance that any acceptor you talk to will fail to implement
>   GSS_Unwrap correctly even if the bit was not set on the wire is
>   vanishingly small(*)

A third SHOULD that is currently missing and needs to be there due to the 
compatibility issue.

> Nonetheless, you've said several times that you shouldn't need to understand 
> the internals of GSS-API.  To a certain extent, I agree with that sentiment, 
> which is why things like the need to set integ_req_flag need to be spelled 
> out in the SASL GSSAPI mechanism specification. Otherwise, someone's going to 
> miss it.

Needs to be spelled out for new implementations.

That doesn't help the tens of thousands of older versions out there.

> I disagree that they failed to communicate the incompatibility to users of 
> RFC 2078.  I think it was entirely reasonable of them to expect that users of 
> RFC 2078 who wanted to use the new version would read RFC 2743, which points 
> out the problem in two places.

You falsely assume that a user of RFC 2078 has nothing to do but to read 
new RFCs, especially when the project to develop RFC 2078 software has 
finished and all that is being done now is *using* that software.

> I expect you to know the versions of things your building against, yes, at 
> least in the cases where it's relevant.  This is a documented interface which 
> has multiple versions; I believe it's reasonable to expect you to know what 
> version you're using.

That is totally unreasonable.

> And another thing you learn, or should, is that stable interfaces, aren't. As 
> you pointed out, RFC 2222 refers to 2078, not 2743.  There's a good reason 
> for that.  Specifications change.  Using a stable reference means that the 
> meaning of RFC 2222 doesn't change out from under you.

But the meaning has changed.  You claim that, magically, RFC 2222 software 
suddenly has to comply with RFC 2743; and that this magic happens at the 
time that some "make" command is done.

>
>>> What you're suggesting is that the new spec _not_ document a new
>>> requirement  of the GSS-API, because your implementation which was
>>> designed for the old  GSS-API fails to meet the requirements of the new
>>> one.  That's just insane.
>> I never said any such thing.
> You objected to the MUST.

I suggested that the MUST be a SHOULD.

Given the stated desire to make this be a requirement in new 
implementations, I backed off for a SHOULD in GSSAPI that preserved 
compatibility -- something that purportedly every GSSAPI implementation 
already does.

> GSS-API implementors are not implementors of this document.  A recommendation 
> to them in this document is useless, because they have no reason to read it.

RFC 2222 implementors are not implementors of RFC 2743.  A requirement 
that RFC 2222 implementors follow RFC 2743 is useless, because they have 
no reason to read RFC 2743.

Therefore, because RFC 2222 does not require the flag, GSSAPI 
implementations used by RFC 2222 software are forbidden to require it. 
All GSSAPI implementors must have a magic crystal ball.

And they must know about this even if they didn't read RFC 2222.

Happy now?

> Your existing deployed code will work JUST FINE.
> If someone comes to you and tells you they built it against a newer GSS-API 
> library and it didn't work, you say "well, it was designed for the version of 
> GSS-API specified by RFC 2222; if you want to use something newer, you may 
> have to upgrade".  I don't think that's at all unreasonable.

Please remind me never to buy a product from any company that you work at.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 29 Aug 2006 22:29:43 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Mark Crispin <[email-masked]>, [email-masked]
cc: [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi) 
Originator-Info: login-token=Mulberry:01z9is8jlAIWYbIyRzAlbcYWZK4x1WDCU8TdpXBVg=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, August 28, 2006 01:39:42 PM -0700 Mark Crispin 
<[email-masked]> wrote:

> I request consideration of the following changes prior to publication.
>
> Page 4, first paragraph, please change:
>     [...]  When calling the GSS_Init_sec_context the client
>     MUST pass the integ_req_flag of TRUE.
> to
>     [...]  When calling the GSS_Init_sec_context the client
>     SHOULD pass the integ_req_flag of TRUE.
>
> Otherwise, publication of this document would have the effect of
> declaring existing deployed software to be non-compliant.  I agree that
> this change is desirable, but I disagree about retroactively declaring
> existing software broken.  If the WG feels strongly enough, it'd be
> alright to have something in the security considerations saying that
> earlier versions did not require the integ_req_flag, but all new
> implementations ought to have it and old implementations fixed.

We've been arguing in another thread, but I think that's starting to get 
too convoluted and maybe we can make things a little simpler.

Your original concern as stated above seems to be that the MUST in the 
present draft "declares existing deploted software to be non-compliant".  I 
do not believe that is the case.  Certainly existing deployed software will 
be non-complient _with the new specification_, but that's OK.  If it 
complies with RFC 2222, then it will _interoperate_ with implementations of 
the new draft, which is all that is needed.

As discussed, the quoted requirement, which is new in this version, 
reflects a change in the GSS-API.  The API change is backward-incompatible, 
meaning that code written to the old API may not obtain the expected 
results when linked against the new API.  RFC 2222 specified the use of the 
old API (the new one did not yet exist), while this document specifies the 
use of the new; thus the difference.

You also expressed concern about what would happen when application code 
written to RFC 2222 is built against a new version of the API without 
changes to reflect the API change.  The answer is that the result would be 
technically noncompliant with RFC 2222 (but only with respect to the choice 
GSS-API version) and would also fail to meet the new requirement introduced 
by RFC 2743 (of course, there's no reason to expect it to do so), but that 
it will almost certainly work anyway.  This is particularly true with 
respect to the Kerberos GSS-API mechanism, to which the present spec is 
limited, because that mechanism does not prescribe any differences in 
behavior depending on whether the integ_req_flag is set.

Sam proposed text describing the reason for the new requirement.  Aside 
from the references to RFC 1508 where RFC 2078 should be referenced, I have 
no objections to that text.

Martin Rex discussed the history of integ_req_flag, and his view of what 
its intended purpose was, and you (Mark) proposed including some portion of 
that in the present document.

While I have no doubt that much of what he says is true (and, in fact, it 
is partially supported by RFC 2743), Martin's explanation is not normative, 
and RFC 2743 does not restrict the use of these flags to the uses described 
by Martin.  Thus, I would consider the addition of such text to constitute 
an attempt to make a normative change to GSS-API Version 2 Update 1, and 
thus out of scope for this document and for the SASL working group.  I also 
believe that such a change would be backward-incompatible, compounding the 
original error, and thus is unsuitable for inclusion in any update to 
GSS-API Version 2 (KITTEN is chartered to produce such an update, but is 
constrained from including incompatible changes).

However, KITTEN is also chartered to produce a possibly-incompatible 
GSS-API Version 3, and should take care to learn from this discussion.  In 
particular, at a minimum a GSS-API v3 should provide a mechanism by which 
it can be clearly distinguished from earlier versions of the API, as well 
as a mechanism by which future incompatible updates can be detected.

-- Jeff

Date: Tue, 29 Aug 2006 21:57:05 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01GlqOx4TCAztmpQZITdi+NrHMxfKhjgeHz7wsUNo=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, August 29, 2006 05:38:49 PM -0700 Mark Crispin 
<[email-masked]> wrote:

>> RFC 2743 defines the GSS-API v2.1, which is an abstract API.
>
> My code was written two years before RFC 2743 existed!!
>
> RFC 2743 may have superceded RFC 2078. However, the normative reference
> in RFC 2222 is to RFC 2078.  That didn't change when RFC 2743 was
> released.

That is _exactly_ my point.  Your implementation of RFC 2222 is compliant, 
as long as it is based on an implementation of RFC 2078, as specified.

As soon as you compiled and linked your code against a library that 
implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant 
with RFC 2222.

> You can not declare a RFC 2222 implementation to be broken, defective, or
> whatever for not complying with a specification that did not even exist
> when the implementation was written.

I'm not doing any such thing.  The present document does not do any such 
thing.  Implementations of the _present_ document will be compliant only if 
they use the version of the GSS-API as specified in RFC 2743, and then only 
if they set integ_req_flag, as required under that spec for applications 
which wish to use integrity services.

>> Presumably, your code builds because the API was designed to be (mostly)
>> backward-compatible.  I agree that the "mostly" is unfortunate and
>> creates an  increased burden for the developer of GSS-API-using
>> applications, since  existing users of GSS_Init_sec_context may build
>> even though the interface  changed in a backward-incompatible way.
>
> Here's the crux of the matter.  Both RFC 2078 and RFC 2743 talk about
> "full, transparent backward compatibility" and the necessity to maintain
> the GSS_Sign, GSS_Verify, GSS_Seal, and GSS_Unseal interfaces for
> backward compatibility.
>
> What's new in RFC 2743 is this text, buried in 2.2.1:
>
>     [...] It is important to recognize, however, that
>     the inclusion of these flags (which are newly defined for GSS-V2)
>     introduces a backward incompatibility with callers implemented to
>     GSS-V1, where the flags were not defined.  Since no GSS-V1 callers
>     would set these flags, even if per-message services are desired,
>     GSS-V2 mechanism implementations which enable such services
>     selectively based on the flags' values may fail to provide them to
>     contexts established for GSS-V1 callers.  It may be appropriate under
>     certain circumstances, therefore, for such mechanism implementations
>     to infer these service request flags to be set if a caller is known
>     to be implemented to GSS-V1.
>
> This text is wrong in saying "GSS-V2" because RFC 2078 is silent on this
> matter and describes Version 2.  It's actually newly defined for Version
> 2, Update 1.

That is correct; the change actually occurred in Version 2, Update 1.  I 
have no idea why this text talks about GSS-v1 vs GSS-v2 rather than about 
GSS-v2 vs GSS-v2u1, but the principle is the same.

>> You're calling GSS_Wrap.  RFC2743 is clear on what you have to do for
>> that to  work.  True, RFC2078 said no such thing, and your
>> implementation is compliant  with 2222 and 2078, at least in this
>> respect.  If you want to upgrade to an  implementation of the new API,
>> you have to make whatever changes are required  to do so.
>
> I want the existing installed base to continue to work.

The existing installed base of RFC2222-compliant implementations will 
continue to work.

Any installed base consisting of code that started as an RFC2222-compliant 
implementation and then had its GSS-v2 replaced by GSS-v2u1 is not 
compliant with anything, but will probably work anyway.

> I'll happily update new releases to comply with the draft (replacing RFC
> 2222), which uses RFC 2743 normatively rather than RFC 2078.

And compliant implementations of the new draft, using RFC4422 and RFC2743, 
will also work, provided the requirement we are talking about is met.  If 
we removed the requirement, then "compliant" implementations that fail to 
meet it might still fail to interoperate.  Again, that's unlikely, but only 
because the present document is restricted to the Kerberos mechanism.

> I object to the implication that it is somehow my fault that in 1998 I
> lacked the clairvoyance to know about an incompatible change that would
> take place in 2000.  I object to my existing releases being labelled
> non-compliant.

Do you seriously think anyone is going to fault your RFC2222 implementation 
for not being compliant with the new specification?  I doubt it.

It is _not_ a requirement, and never has been, that a new protocol 
specification be written such that older implementations be compliant with 
the new spec.  That would be silly, as it would essentially prevent the 
introduction of new features.

What is and has been at least strongly desired, if not actually required, 
is that a new protocol specification be written such that compliant 
implementations of the old version will interoperate with compliant 
implementations of the new version.  I believe we have done that here.

> I read RFC 2078.  Cover to cover.  I am starting to get angry.

I'm sorry; I misspoke, and probably more than once.  What I meant to say 
was that you apparently did not read RFC2743 before starting to use a newer 
GSSAPI library based on it.  I say that because I fail to understand how 
you could have read RFC 2743 and _not_ noticed the warning about the 
backward incompatibility.  I suppose you could have seen the warning and 
not realized it was relevant to what you were doing, but you can hardly 
fault RFC 2222 for not pointing out the issue.

And chances are that even if you did, you _still_ have nothing to worry 
about, because

(a) the library you are using probably sets the bit on the wire even if
    you don't request it
(b) the library you are using implements GSS_Wrap correctly, including
    producing tokens with correct integrity checks, even if you didn't
    request integrity service (if this were not true, you'd already be
    seeing serious interop problems)
(c) the chance that any acceptor you talk to will fail to implement
    GSS_Unwrap correctly even if the bit was not set on the wire is
    vanishingly small(*)

Nonetheless, you've said several times that you shouldn't need to 
understand the internals of GSS-API.  To a certain extent, I agree with 
that sentiment, which is why things like the need to set integ_req_flag 
need to be spelled out in the SASL GSSAPI mechanism specification. 
Otherwise, someone's going to miss it.

> I also see that RFC 2743 practically apologizes for creating a backwards
> incompatibility on page 97:
>        [...]  (Note: this facility introduces a
>        backward incompatibility with GSS-V1 callers, discussed in Section
>        2.2.1; this implication was recognized and accepted in working
>        group discussion.)
>
> Quite frankly, the working group did a lousy job, both in creating the
> incompatibility and in failing to communicate it to people who had used
> RFC 2078 in the past.

I agree that the working group did a lousy job in creating the 
incompatibility, particularly since I can see a trivial way they could have 
avoided the problem.  However, I take no responsibility for that; I wasn't 
involved in the IETF when that document was published.

I disagree that they failed to communicate the incompatibility to users of 
RFC 2078.  I think it was entirely reasonable of them to expect that users 
of RFC 2078 who wanted to use the new version would read RFC 2743, which 
points out the problem in two places.

>> The other thing you also did, apparently, was to take your RFC2222
>> implementation and use it with a newer version of the GSS-API than was
>> used  by that document.
>
> How the hell am I supposed to know that?
>
> Do you really believe that, prior to any compilation, a developer goes
> and checks the version numbers and seeks out the release notes of every
> single API, DLL, shared library, etc. ad nauseum that his application
> might use?

I expect you to know the versions of things your building against, yes, at 
least in the cases where it's relevant.  This is a documented interface 
which has multiple versions; I believe it's reasonable to expect you to 
know what version you're using.  I certainly know of plenty of software 
which checks at build time that the available libraries are suitable for 
its needs, and I also know of some very widely used libraries whose API's 
are well-known for changing significantly at the drop of a hat.

> One thing that you learn from the experience is to keep layers separate,
> and treat published interfaces as holy.

And another thing you learn, or should, is that stable interfaces, aren't. 
As you pointed out, RFC 2222 refers to 2078, not 2743.  There's a good 
reason for that.  Specifications change.  Using a stable reference means 
that the meaning of RFC 2222 doesn't change out from under you.

> It is still incumbent upon GSSAPI to maintain backwards compatibility.

No, it's not.  I agree that it would be best if it did so,

>> What you're suggesting is that the new spec _not_ document a new
>> requirement  of the GSS-API, because your implementation which was
>> designed for the old  GSS-API fails to meet the requirements of the new
>> one.  That's just insane.
>
> I never said any such thing.

You objected to the MUST.

> I said that the fact that this is a new requirement needs to be
> explicitly documented in a changes section; and furthermore there should
> be a recommendation (as there is in RFC 2743) that GSSAPI implementations
> not enforce this requirement due to backward compatibility for RFC 2222
> implementations.

GSS-API implementors are not implementors of this document.  A 
recommendation to them in this document is useless, because they have no 
reason to read it.

> How does that differ from an RFC xxxx implementation (where xxxx is
> whatever RFC number this draft gets)?

I believe I answered that in the following paragraph.  It shouldn't differ 
at all, provided there are no other differences between the present 
document and the mechanism as specified in RFC 2222(*).  I say "shouldn't" 
because there is always the possibility of an error.

(*) At this point, I feel compelled to point out to observers that RFC 2222
    contains the previous versions of both the base SASL specification, now
    RFC 4422, and the SASL GSSAPI mechanism which is the subject of the
    present document.

> You still haven't answered what happens with the RFC 2222 implementations
> that are already out there.  Nobody wants (or not wants) them to be built
> against RFC 2743.  It just happens.

That is true, it does happen.  In fact, it is frequently the case that some 
spec "A" refers to a particular verison of spec "B", but implementations of 
"A" become commonplace in which the "B" component has been replaced by a 
newer version.  I agree that as protocol designers and implementors, we 
should strive to make those cases work whenever possible, because the 
alternative is an unsustainable tangled mass of different versions of 
things.

So, what happens when code that was written as an implementation of RFC 
2222 in terms of some GSS-v2 is instead built against GSS-v2u1?  Well, the 
usual thing happens - you end up with something that is technically not 
compliant with any specification, but works just fine.

Let me repeat that...

Your existing deployed code will work JUST FINE.
If someone comes to you and tells you they built it against a newer GSS-API 
library and it didn't work, you say "well, it was designed for the version 
of GSS-API specified by RFC 2222; if you want to use something newer, you 
may have to upgrade".  I don't think that's at all unreasonable.

>> It's not a bug in 2222; the flag didn't exist then.
>> It's also not a change in GSSAPI 2.1 that broke 2222, because 2222
>> refers to  RFC2078, which defines GSSAPI 2.0.  There's a reason why we
>> generally make  references to immutable identifiers like RFC's, rather
>> than to STD numbers,  and this situation illustrates that reason
>> perfectly.
>
> In that case, then this new draft can not define the GSSAPI SASL
> mechanism, because that mechanism is defined by RFC 2222 and the new
> draft is incompatible.

No; that is not the case.  RFC 2222 implementations will not be compliant 
with the new draft, but that's to be expected.  They _will_ interoperate 
with implementations of the new draft.  This is not a different mechanism.

>> I will agree that GSSAPI v2.1 is incompatible with older versions in
>> this  respect.  I'll even agree that the new functionality could have
>> been added in  a way that was not backward-incompatible.  However, that
>> was over 6 years  ago, before I was involved in the IETF, and it's
>> pretty much a done deal now.
>
> What were you doing before you were involved in the IETF?

I don't think that's relevant to the present discussion, and I doubt the 
entire memberships of the SASL and Kitten WG's and the entire IESG are 
interested in the tangent.  I'll be happy to take it offline, if you wish.

>> the  GSS-API as specified in RFC 2078, are indeed not to blame for the
>> situation.  Those who updated their implementations to use a newer
>> implementation of the  GSS-API without dealing with new requirements
>> that RFC 2222 could not  possibly have known about, have less of a leg
>> to stand on.
>
> I am not aware of having updated my implementation to use a newer
> implementation of GSSAPI.  What you think that I did so?
>
> Do you think that compiling my application after 2000 constitutes
> "updating my implementation to use a newer version of GSSAPI"?

Not if you compiled it against a GSS-v2 library.  If you compiled it 
against a GSS-v2u1 library, then yes.  Or rather, that would be "using a 
newer version of GSSAPI without making changes to your application", but 
that's what I meant.

> Currently, the fact that RFC 2222 does not require the flag effectively
> prevents GSSAPI implementations from enforcing the requirement.

No, it doesn't.  It means that code intended as an RFC 2222 implementation 
may not work if built against the wrong GSS-API library.  But since the 
reality is that they almost certainly will, I really think you're making a 
mountain out of a molehill.

-- Jeff

Date: Tue, 29 Aug 2006 20:54:32 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: [email-masked], Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
Originator-Info: login-token=Mulberry:01f7A8JOkYsZjL+7Slsi5skxYic08G5LXsJWqJtTA=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, August 30, 2006 01:55:56 AM +0200 Martin Rex 
<[email-masked]> wrote:

> So the general recommendation of the GSS-API spec becomes even
> more important: an application ought to check context attributes
> when context establishment succeeds and decide whether it wants
> to use the resulting security context or not

Yes; this is an absolute requirement, because as defined the API is allowed 
to give you a context that doesn't meet your needs.  This is why RFC4462, 
for example, clearly spells out the flags that must be checked after 
context establishment.  I'd really prefer to see this document do the same, 
but we've had that argument.

> The server/accepter
> doesn't have a means to indicates its desires/requirements,
> anyway.

True, but it does have the means to check that its requirements are met by 
the established context.  I've always believed that is was sufficient to 
have the input provided only by one party because both parties are 
implementations of the same protocol, and thus if you have a protocol in 
which only the acceptor generates tokens requiring integrity services, the 
initiator is still aware of it and can indicate the need for that service. 
Again, I cite RFC 4462 as an example of this -- in SSH key exchange, the 
SSH server acts as GSSAPI acceptor, and calls GSS_GetMic to generate the 
only message token ever produced using that context.  The initiator never 
calls GSS_GetMIC, but is nonetheless required to set integ_req_flag, 
because the protocol requires integrity service.

>> A more serious problem case is a client that does not support gss_wrap
>> when integ_flag is not set in gss_init_sec_ctx.  I believe such a
>> client could not possibly work with RFC 2222 or this spec.  However I
>> think such a client is compatible with GSS-API.
>
> I think that a client (gsssapi mechanism implementation capable of
> message integrity protection) is both non-compliant with GSS-API
> and seriously broken if it denies message integrity services
> only because the initiator didn't assert integ_req_flag when it
> called gss_init_sec_context().
>
> The wording in RFC2743 is to improve "portability" for applications
> even for newer negotiating mechanisms.  It was never meant to
> imply that it would be OK for gssapi mechanism implementations
> to make stupid backwards incompatible changes just for the sake
> of the fun of it.

"For the fun of it" ?   Of course not.  However, I can envision a mechanism 
for which providing integrity or confidentiality services requires an extra 
round trip at context establishment time, and which avoids that round trip 
if those services were not requested.  Such a mechanism would be _unable_ 
to provide those services on a context if they had not been requested (and, 
of course, would not indicate their availability on such a context).

RFC2743 indicates that these flags are provided "primarily to provide 
information to negotiating mechanisms" (Appendix B), but does not preclude 
other uses of that information.  In fact, it says the following (2.2.1):

   ... Since no GSS-V1 callers
   would set these flags, even if per-message services are desired,
   GSS-V2 mechanism implementations which enable such services
   selectively based on the flags' values may fail to provide them to
   contexts established for GSS-V1 callers.

This text clearly permits the existence of mechanisms which selectively 
enable confidentiality and/or integrity services on the basis of whether 
they are requested during context establishment.

-- Jeff

Date: Tue, 29 Aug 2006 17:41:47 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Jeffrey Altman <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 29 Aug 2006, Jeffrey Altman wrote:
> does the text proposed by Sam Hartman meet your needs?

It helps.  Could some part of what Martin Rex wrote also be incorporated?

Thanks,

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 29 Aug 2006 17:40:15 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Martin Rex <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
Organization: Networks & Distributed Computing
Sender: [email-masked]

Martin, thank you.

Now, can we get something to this effect in the document?

On Wed, 30 Aug 2006, Martin Rex wrote:
> I think that a client (gsssapi mechanism implementation capable of
> message integrity protection) is both non-compliant with GSS-API
> and seriously broken if it denies message integrity services
> only because the initiator didn't assert integ_req_flag when it
> called gss_init_sec_context().
>
> The wording in RFC2743 is to improve "portability" for applications
> even for newer negotiating mechanisms.  It was never meant to
> imply that it would be OK for gssapi mechanism implementations
> to make stupid backwards incompatible changes just for the sake
> of the fun of it.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 29 Aug 2006 17:38:49 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
>> I have no idea what version of GSSAPI I implemented against.
> You used an API without paying attention to what version of the API you were 
> using?  How is that my problem?

At the time that RFC 2222 came out, there was no mention of backward 
incompatibility in GSSAPI versions, nor of tests to determine which 
version to use.  Do you expect that, years ago, I would somehow use some 
crystal ball to know about something happened in the future?

>> I followed
>> the instructions in RFC 2222.
> ... without reading the documents to which it referred, apparently.

What are you talking about?

RFC 2222 refers to RFC 2078.  RFC 2078 says nothing whatsoever about 
integ_req_flag.

RFC 2078 talks about GSSAPI versions, but says little about them other 
than passing references to interfaces maintained for compatibility with 
earlier versions.

> This is 
> precisely the reason for stating the requirement to set integ_req_flag in 
> this new document - because if we don't, then people implementing the 
> mechanism won't bother to read the GSS-API documents, even though they're 
> writing what is essentially a GSS-API application, and will miss this 
> requirement.

Regardless of whether that statement is true or not, it does not apply to 
me.

I read RFC 2078.  Cover to cover.  I did what it said.

> RFC 2743 defines the GSS-API v2.1, which is an abstract API.

My code was written two years before RFC 2743 existed!!

RFC 2743 may have superceded RFC 2078. However, the normative reference in 
RFC 2222 is to RFC 2078.  That didn't change when RFC 2743 was released.

You can not declare a RFC 2222 implementation to be broken, defective, or 
whatever for not complying with a specification that did not even exist 
when the implementation was written.

> If you are actually _implementing_ a protocol that uses the GSS-API, then you 
> also need to read the language bindings document for the language you are 
> using; for C, this is RFC 2743.

Has CMU built a working time machine, and have they sent that time machine 
back to 1998?

If not, please explain how, in 1998, an implementor could possibly comply 
with the requirements of RFC 2743 which was issued in 2000.

>> If this is the "old API", then how does it have GSS_C_INTEG_FLAG if it is
>> not in the "old API"?  If this is the "new API", then how does my code,
>> written to comply with RFC 2222, build under it?
> Well, given that GSS_C_INTEG_FLAG exists, I'd guess that the library you're 
> building against is an implementation of GSS-API v2.1.  To be sure, you 
> should probably check whatever documentation came with it.

That is not a particularly helpful comment.

Not everybody uses a system that they personally built from individual 
libraries.  Many people use systems that were built from others.

> Presumably, your code builds because the API was designed to be (mostly) 
> backward-compatible.  I agree that the "mostly" is unfortunate and creates an 
> increased burden for the developer of GSS-API-using applications, since 
> existing users of GSS_Init_sec_context may build even though the interface 
> changed in a backward-incompatible way.

Here's the crux of the matter.  Both RFC 2078 and RFC 2743 talk about 
"full, transparent backward compatibility" and the necessity to maintain 
the GSS_Sign, GSS_Verify, GSS_Seal, and GSS_Unseal interfaces for backward 
compatibility.

What's new in RFC 2743 is this text, buried in 2.2.1:

    [...] It is important to recognize, however, that
    the inclusion of these flags (which are newly defined for GSS-V2)
    introduces a backward incompatibility with callers implemented to
    GSS-V1, where the flags were not defined.  Since no GSS-V1 callers
    would set these flags, even if per-message services are desired,
    GSS-V2 mechanism implementations which enable such services
    selectively based on the flags' values may fail to provide them to
    contexts established for GSS-V1 callers.  It may be appropriate under
    certain circumstances, therefore, for such mechanism implementations
    to infer these service request flags to be set if a caller is known
    to be implemented to GSS-V1.

This text is wrong in saying "GSS-V2" because RFC 2078 is silent on this 
matter and describes Version 2.  It's actually newly defined for Version 
2, Update 1.

In any case, RFC 2222 callers are known to be implemented to pre-V2.1 
versions of GSSAPI.

> You're calling GSS_Wrap.  RFC2743 is clear on what you have to do for that to 
> work.  True, RFC2078 said no such thing, and your implementation is compliant 
> with 2222 and 2078, at least in this respect.  If you want to upgrade to an 
> implementation of the new API, you have to make whatever changes are required 
> to do so.

I want the existing installed base to continue to work.

I'll happily update new releases to comply with the draft (replacing RFC 
2222), which uses RFC 2743 normatively rather than RFC 2078.

I object to the implication that it is somehow my fault that in 1998 I 
lacked the clairvoyance to know about an incompatible change that would 
take place in 2000.  I object to my existing releases being labelled 
non-compliant.

>> Now you tell me that it does, and that it's all my fault for making the
>> false assumption that I had integrity when I did not.  The problem with
>> that is that it assumes that I, implementing from RFC 2222, knew enough
>> about the internals of GSSAPI to make that kind of assumption.
> Right; you read RFC2222 and apparently didn't bother to read 2078 or 1509 in 
> detail. That's kind of poor, but it's also to be expected

Just where did you get that notion?

I read RFC 2078.  Cover to cover.  I am starting to get angry.

Please point to text in RFC 2078 that states the requirement to have ESP 
to know that an incompatible change would take place two years later. 
Please point to text in RFC 2078 that implies that GSSAPI would be so 
callous about the question of background incompatibility.

I also see that RFC 2743 practically apologizes for creating a backwards 
incompatibility on page 97:
       [...]  (Note: this facility introduces a
       backward incompatibility with GSS-V1 callers, discussed in Section
       2.2.1; this implication was recognized and accepted in working
       group discussion.)

Quite frankly, the working group did a lousy job, both in creating the 
incompatibility and in failing to communicate it to people who had used 
RFC 2078 in the past.

> The other thing you also did, apparently, was to take your RFC2222 
> implementation and use it with a newer version of the GSS-API than was used 
> by that document.

How the hell am I supposed to know that?

Do you really believe that, prior to any compilation, a developer goes and 
checks the version numbers and seeks out the release notes of every single 
API, DLL, shared library, etc. ad nauseum that his application might use?

> Now, RFC2222 couldn't possibly have warned you about 
> changes required by RFC2743.  The new specification can, and should.

And I made the change in the new release.  But that doesn't do anything 
about the tens of thousands of copies released using the information in 
the old documents.

>> RFC 2222 goes to great efforts to hide what GSSAPI does.
> From application protocol designers and implementors, not from mechanism 
> implementors.  You wouldn't expect to implement TCP without understanding IP, 
> would you?

Have you ever implemented a TCP?  I have.  I've also done an NCP.

One thing that you learn from the experience is to keep layers separate, 
and treat published interfaces as holy.

> You'd have the same problem if you wrote your application against an older 
> version of some Kerberos API

If I had known that the Kerberos API developers were so incompetant in 
maintaining API compatibility, I would have implemented the entire 
protocol by hand.  That way, I wouldn't be vulnerable to capricious 
changes in the API.  They may change the bits on the wire, but not without 
breaking their software as much as they break mine.

> When RFC2222 was written, its authors told you about what you needed to do in 
> order to use the version of the GSS-API that was available at that time. Now, 
> we're telling you what you need to do in order to use the version of the 
> GSS-API that's available now.

It is still incumbent upon GSSAPI to maintain backwards compatibility.

> What you're suggesting is that the new spec _not_ document a new requirement 
> of the GSS-API, because your implementation which was designed for the old 
> GSS-API fails to meet the requirements of the new one.  That's just insane.

I never said any such thing.

I said that the fact that this is a new requirement needs to be explicitly 
documented in a changes section; and furthermore there should be a 
recommendation (as there is in RFC 2743) that GSSAPI implementations not 
enforce this requirement due to backward compatibility for RFC 2222 
implementations.

>> What is "an RFC2222 implementation...with integ_req_flag"?  RFC 2222 is
>> silent on the matter.
> I mean an RFC2222 implementation, built against a RFC2743 implementation, 
> which sets integ_req_flag in its calls to GSS_Init_sec_context. In other 
> words, what _should_ be the result of forward-porting an existing RFC2222 
> implementation to the new API.

How does that differ from an RFC xxxx implementation (where xxxx is 
whatever RFC number this draft gets)?

You still haven't answered what happens with the RFC 2222 implementations 
that are already out there.  Nobody wants (or not wants) them to be built 
against RFC 2743.  It just happens.

> It's not a bug in 2222; the flag didn't exist then.
> It's also not a change in GSSAPI 2.1 that broke 2222, because 2222 refers to 
> RFC2078, which defines GSSAPI 2.0.  There's a reason why we generally make 
> references to immutable identifiers like RFC's, rather than to STD numbers, 
> and this situation illustrates that reason perfectly.

In that case, then this new draft can not define the GSSAPI SASL 
mechanism, because that mechanism is defined by RFC 2222 and the new 
draft is incompatible.

The new draft must therefore define the GSSAPIv21 SASL mechanism.

> I will agree that GSSAPI v2.1 is incompatible with older versions in this 
> respect.  I'll even agree that the new functionality could have been added in 
> a way that was not backward-incompatible.  However, that was over 6 years 
> ago, before I was involved in the IETF, and it's pretty much a done deal now.

What were you doing before you were involved in the IETF?

> Implementors who followed RFC 2222, including using an implementation of the 
> GSS-API as specified in RFC 2078, are indeed not to blame for the situation. 
> Those who updated their implementations to use a newer implementation of the 
> GSS-API without dealing with new requirements that RFC 2222 could not 
> possibly have known about, have less of a leg to stand on.

I am not aware of having updated my implementation to use a newer 
implementation of GSSAPI.  What you think that I did so?

Do you think that compiling my application after 2000 constitutes 
"updating my implementation to use a newer version of GSSAPI"?

>> (2) RFC 2222 implementors MUST take note of the new requirement to set
>>      integ_req_flag, and MUST upgrade their implementations.  Although all
>>      known GSSAPI 2.1 implementations treat it as set, this behavior can
>>      not be relied upon.
> RFC 2222 is immutable.  To say "RFC 2222 implementors MUST..." is 
> nonsensical.  Implementors of _this_ spec already MUST set the flag, and 
> anything that's not an implementation of this spec is not subject to the 
> requirement anyway.

RFC 2222 implementors need to be informed.  Their implementations may 
break, depending upon the caprice of whomever supplies the GSSAPI.

Currently, the fact that RFC 2222 does not require the flag effectively 
prevents GSSAPI implementations from enforcing the requirement.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 29 Aug 2006 20:38:06 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, [email-masked], [email-masked], [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Proposed updates for domain-based drafts
Originator-Info: login-token=Mulberry:01xg8Q3DB3hVASWohd+Y1AS12BRwdNQ4kzhD5B/I8=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, August 29, 2006 03:57:24 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> Issues that came up:
>
>  - Sam wanted a better outline of how applications might use
>    domain-based names.  I'm not sure whether Sam wants text for the
>    drafts or merely discussion on the list.

Neither am I, but I thought the original point was to demonstrate that 
domain-based names as specified are workable in practice.  To that end, I 
will note that there is an existing widely-deployed implementation of LDAP 
using GSS-krb5 with domain-based service names substantially as specified 
here.  We've also discussed how to make use of them in SSH and in NFSv4, 
and in neither case is the answer Kerberos-specific.

It seems clear that the determination of when to use the domain-based name 
form must be made by the application.  In the case of NFSv4, the client 
knows a priori whether it is supposed to be mounting an individual 
fileserver or the root of a namespace belonging to some domain, and 
domain-based names are used only in the latter case.  Referrals always list 
the names of one or more specific servers, and the mounts resulting from 
them would always use host-based names.

In the case of SSH, the use of domain-based names for key exchange would be 
negotiated by the use of an alternate family of algorithm names; an SSH 
server would be required to know whether it possesses suitable acceptor 
credentials for use with domain-based names, and only advertise the 
mechanism in that case.  This is similar to the current model, in which an 
SSH server only advertises support for GSS-API mechanisms for which it has 
acceptor credentials.

I don't think it's necessary for this document to describe how domain-based 
names might be used in existing protocols.  In fact, I believe that doing 
so may be actively harmful, because it may lead to people treating such 
text as if it were a mature protocol specification rather than a 
proof-of-concept, possibly even after a real spec has been published.

>     - A clarification on just what is a "domain"

You haven't actually said anything here in response to this, but we 
discussed this offline and I believe we came to the conclusion that the 
determination of the correct domain to use is up to the application.  In 
particular, we have between us seen at least three possible choices, 
depending on the intended use:

- For services for which service for a specified domain is provided by
  one or more servers identified by SRV records or some similar mechanism,
  you probably want to use the same base domain name used to construct the
  names of SRV records.  For example, if you are connecting to the LDAP
  service for the domain EXAMPLE.ORG, you'd look for DNS SRV records under
  the name _ldap._tcp.EXAMPLE.ORG, and use a domain-based service name like
  [email-masked]@ldap1.example.org.  This is probably the correct model
  for LDAP, and also for NFSv4.

- For services for which service for a single name may be provided by one
  or more servers sharing a name, you probably want to use the shared name
  as the domain name, and obtain hostnames by reverse resolution.  This is
  the model I'd expect to see used for SSH (for example, to provide a pool
  of time-sharing machines behind a single hostname).

- Nico envisioned services in which one might provide different "instances"
  for the same domain name, which would necessitate building domain-based
  service names using the full name used to construct SRV records (for
  example, [email-masked]@foobar1.example.com) and/or
  attach some instance designator to the domain name.  I can't think of
  any concrete examples where this is needed, but that doesn't mean that
  there aren't any, or that there can't be any in the future.

Essentially, the correct choice of name form really needs to be up to the 
application, or at least to something above the GSS-API layer.  We might 
provide examples like the ones I just gave, but I don't think that's 
necessary, either; the existing text seems fine on this point.

>     - A new feature in the Kerberos V GSS-API mechanism relating to
>       domain-based names: initiator-side fallback on hostbased naming
>       with domainnames as hostnames with acceptor-side acceptor
>       credential sharing.

> With respect to SASL I believe there is nothing for either of these two
> I-Ds to say on the matter.  I believe applications and SASL/GS1 and/or
> SASL/GS2 will require updating to specify use of domain-based names in
> SASL contexts.  I don't believe that we absolutely must update the SASL
> base specification to introduce new kinds of server names, but I don't
> mind us doing so -- either way the I-Ds we're considering in this WGLC
> are unaffected.

I believe there is clearly work to be done in this area as it relates to 
SASL.  The question of whether and when to use domain-based names and of 
what domain name to use needs to be answered, and in the case of SASL, it 
is likely to be application-specific.  However, we need to be careful not 
to introduce unnecessary complexity or a need for applications to have 
mechanism-specific knowledge.

In any event, I agree with Nico that neither of Kitten's domain-based name 
drafts need to address the SASL question.

> After some off-line discussion with Jeff about his proposed new feature
> we reached a compromise.  We propose the following change to
> draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt:
>
> -   GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal
> -   names as follows:
> +   GSS_C_NT_DOMAINBASED_SERVICE name SHOULD be mapped to Kerberos V
> +   principal names as follows:
>
> This will allow for a future document that specifies Jeff's fallback
> feature.

In fact, it retains nearly all the strength of the original statement, 
while still allowing for compliant implementations that can be configured 
to map domain-based names differently.  I believe that SHOULD as defined in 
RFC2119 is quite strong enough for this purpose.

-- Jeff

From: Martin Rex <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
To: [email-masked] (Sam Hartman)
Date: Wed, 30 Aug 2006 01:55:56 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Sam Hartman wrote:
> 
> It's a really strong belief.
> Factors that contribute to this belief:
> 
> * Neither RFC 2222 nor this spec specify what to do if integrity
>   protection is not available on a context.
> 
> * gss_wrap only works if integrity protection is available.
> 
> * The caller will call gss_unwrap on the input token.  There is no way
>   under RFC 1964 nor RFC 4121 to produce  a token without integrity protection.

For many years no-one in the cat-ietf working group had thought about
gssapi mechanisms that do not have message integrity.  They simply
didn't exist.

When one vendor/implementor proposed an authentication-only gssapi
mechanism during an IETF meeting (gave a presentation), people
started wondering about the implications.

It was realized that GSS-API (high level and C-bindings) did not
cover this case.  It is unspecified what the message protection
functions will do in that case.  gss_getmic()/gss_verifymic()
are likely going to fail (but aren't required to).
gss_getmic() definitely MUST NOT return an empty output token, however.

gss_wrap() might work, and for the sake of simplistic application
level protocol framing it would be useful if gss_wrap()/gss_unwrap()
actually worked even when no integrity protection was provided.

IMHO, having get_mic/verify_mic and wrap/unwrap succeed in absence
of messsage integrity services might easily give an application
a false sense of security.  gss_wrap/gss_unwrap can only indicate
availability/unavailability of confidentiality in a non-ambiguous way,
it can not do that with message integrity.  QOPs are non-portable.

But ultimately, it is un(der)specified at the GSS-API level,

So the general recommendation of the GSS-API spec becomes even
more important: an application ought to check context attributes
when context establishment succeeds and decide whether it wants
to use the resulting security context or not--because a GSS-API
mechanism ought to successfully establish a security context
even when it doesn't meet the callers desires.  The server/accepter
doesn't have a means to indicates its desires/requirements,
anyway.

> 
> A more serious problem case is a client that does not support gss_wrap
> when integ_flag is not set in gss_init_sec_ctx.  I believe such a
> client could not possibly work with RFC 2222 or this spec.  However I
> think such a client is compatible with GSS-API.

I think that a client (gsssapi mechanism implementation capable of
message integrity protection) is both non-compliant with GSS-API
and seriously broken if it denies message integrity services
only because the initiator didn't assert integ_req_flag when it
called gss_init_sec_context().

The wording in RFC2743 is to improve "portability" for applications
even for newer negotiating mechanisms.  It was never meant to
imply that it would be OK for gssapi mechanism implementations
to make stupid backwards incompatible changes just for the sake
of the fun of it.

-Martin

Date: Tue, 29 Aug 2006 18:16:17 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01y3PZ9jXbTmoXvlF3/vEJZWLlECFSp1I46AdbAfM=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, August 29, 2006 01:57:28 PM -0700 Mark Crispin 
<[email-masked]> wrote:

> On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
>> Right.  RFC2743 makes it quite clear that callers which do not set
>> integ_req_flag may not be able to make use of integrity services.  It
>> also  addresses the interoperability issues with applications written
>> against older  versions of the API, recommending that mechanisms behave
>> as if the flag were  set when the caller is known to be using the old
>> API.
>
> Can you elaborate on "when the caller is known to be using the old API"?

Nope; I was paraphrasing RFC2743.  I don't know what scenario its authors 
were envisioning, but I assume it involved some sort of out-of-band 
knowledge.

>> Right.  If your SASL implementation is written against a GSS-API v1
>> library,  then you have nothing to worry about, because that flag did
>> not exist then.  If you have been linking it against a v2 library, then
>> you had to deal with  the API changes in v2, and if you failed to not
>> that you needed to set  integ_req_flag, then that is your own problem.
>
> Say what???
>
> I have no idea what version of GSSAPI I implemented against.

You used an API without paying attention to what version of the API you 
were using?  How is that my problem?

> I followed
> the instructions in RFC 2222.

... without reading the documents to which it referred, apparently.  This 
is precisely the reason for stating the requirement to set integ_req_flag 
in this new document - because if we don't, then people implementing the 
mechanism won't bother to read the GSS-API documents, even though they're 
writing what is essentially a GSS-API application, and will miss this 
requirement.

> I look in my /usr/kerberos/include/gssapi/gssapi.h and see that there is
> a GSS_C_INTEG_FLAG defined with the other flags that can be supplied to
> the 6th argument to gss_init_sec_context.  I assume, in good faith, that
> that is what you are talking about when you say "integ_req_flag"; just
> like I assume, in good faith, that the gss_init_sec_context() function is
> what you are talking about when you refer to GSS_Init_sec_context.

RFC 2743 defines the GSS-API v2.1, which is an abstract API.  This is what 
protocol specifications such as RFC 4422 or the present GSS-API SASL 
mechanism document need to reference.  It describes the semantics of the 
GSS-API along with a few wire protocol bits.

If you are actually _implementing_ a protocol that uses the GSS-API, then 
you also need to read the language bindings document for the language you 
are using; for C, this is RFC 2743.  It is this document that tells you how 
GSS-API data types are represented in that language, what the values of 
constants are, the actual names of functions to call, etc.

So yes, when I refer to GSS_Init_sec_context, which is an operation 
provided by the abstract API, that is the same as the C-language function 
gss_init_sec_context(), and the Java method GSSContext.initSecContext().

> If this is the "old API", then how does it have GSS_C_INTEG_FLAG if it is
> not in the "old API"?  If this is the "new API", then how does my code,
> written to comply with RFC 2222, build under it?

Well, given that GSS_C_INTEG_FLAG exists, I'd guess that the library you're 
building against is an implementation of GSS-API v2.1.  To be sure, you 
should probably check whatever documentation came with it.

Presumably, your code builds because the API was designed to be (mostly) 
backward-compatible.  I agree that the "mostly" is unfortunate and creates 
an increased burden for the developer of GSS-API-using applications, since 
existing users of GSS_Init_sec_context may build even though the interface 
changed in a backward-incompatible way.

> I don't want (or not want) integrity services to work.

You're calling GSS_Wrap.  RFC2743 is clear on what you have to do for that 
to work.  True, RFC2078 said no such thing, and your implementation is 
compliant with 2222 and 2078, at least in this respect.  If you want to 
upgrade to an implementation of the new API, you have to make whatever 
changes are required to do so.

The present discussion is about a specification that is being upgraded from 
using RFC2078 to using RFC2743, and about a change that is required as a 
result of that upgrade.

> Now you tell me that it does, and that it's all my fault for making the
> false assumption that I had integrity when I did not.  The problem with
> that is that it assumes that I, implementing from RFC 2222, knew enough
> about the internals of GSSAPI to make that kind of assumption.

Right; you read RFC2222 and apparently didn't bother to read 2078 or 1509 
in detail.  That's kind of poor, but it's also to be expected, and it's why 
2222 and the present document and other specifications of GSS-API-using 
applications need to be specific about these things.

The other thing you also did, apparently, was to take your RFC2222 
implementation and use it with a newer version of the GSS-API than was used 
by that document.  Now, RFC2222 couldn't possibly have warned you about 
changes required by RFC2743.  The new specification can, and should.

> RFC 2222 goes to great efforts to hide what GSSAPI does.

>From application protocol designers and implementors, not from mechanism 
implementors.  You wouldn't expect to implement TCP without understanding 
IP, would you?

> That way, I wouldn't have to deal with surprises like
> "You must set this bit when you call GSSAPI.  True, we didn't tell you
> about it back then, but it's still your fault for not knowing about it."

You'd have the same problem if you wrote your application against an older 
version of some Kerberos API (note that there is no standardized one) and 
then built it against a newer version with different requirements, or 
against a different implementation with different requirements.

When RFC2222 was written, its authors told you about what you needed to do 
in order to use the version of the GSS-API that was available at that time. 
Now, we're telling you what you need to do in order to use the version of 
the GSS-API that's available now.

What you're suggesting is that the new spec _not_ document a new 
requirement of the GSS-API, because your implementation which was designed 
for the old GSS-API fails to meet the requirements of the new one.  That's 
just insane.

>> An RFC2222 implementation using GSS-API v1 will work just fine.
>> An RFC2222 implementation using GSS-API v2.1 with integ_req_flag will
>> work. An RFC2222 implementation using GSS-API v2.1 without
>> integ_req_flag is  already wrong, but probably works anyway.
>
> What is "an RFC2222 implementation...with integ_req_flag"?  RFC 2222 is
> silent on the matter.

I mean an RFC2222 implementation, built against a RFC2743 implementation, 
which sets integ_req_flag in its calls to GSS_Init_sec_context.  In other 
words, what _should_ be the result of forward-porting an existing RFC2222 
implementation to the new API.

> If it does not upgrade the implementation from RFC 2222 to RFC xxxx (I
> read the draft and I didn't see any other matter that call for a change),
> why not and what else do I need to do?

If that's the only change, then yes, making the change brings you into 
compliance with the new spec.  But for the purpose of this discussion, I 
wasn't going to make any assumptions about whether there were other changes.

>> A different GSS-API v2.1 library
>> would be entirely within its rights to make it not work, under the
>> existing  GSS-API specification.  RFC2222, RFC4422, and this spec have
>> nothing to do  with it.
>
> I strongly disagree.  Either this is a bug in RFC 2222, or is an
> incompatibility in GSSAPI 2.1 that broke RFC 2222.

It's not a bug in 2222; the flag didn't exist then.
It's also not a change in GSSAPI 2.1 that broke 2222, because 2222 refers 
to RFC2078, which defines GSSAPI 2.0.  There's a reason why we generally 
make references to immutable identifiers like RFC's, rather than to STD 
numbers, and this situation illustrates that reason perfectly.

I will agree that GSSAPI v2.1 is incompatible with older versions in this 
respect.  I'll even agree that the new functionality could have been added 
in a way that was not backward-incompatible.  However, that was over 6 
years ago, before I was involved in the IETF, and it's pretty much a done 
deal now.

> Either way, it is not
> a good thing that this came to pass, and the innocent implementors who
> followed RFC 2222 are not to blame for the situation.

Implementors who followed RFC 2222, including using an implementation of 
the GSS-API as specified in RFC 2078, are indeed not to blame for the 
situation.  Those who updated their implementations to use a newer 
implementation of the GSS-API without dealing with new requirements that 
RFC 2222 could not possibly have known about, have less of a leg to stand 
on.  Remember, a large part of the _reason_ for the present document is to 
update the GSS-API SASL mechanism spec to reflect those new requirements.

Sometimes being ahead of the curve hurts.
In this case, it won't, really, because the likelyhood that you're actually 
going to see an interoperability problem is vanishingly small.

> If this is so, do you agree that this is an incompatible (and
> unfortunate) change in GSSAPI 2.1?

Yes, but it's too late to do anything about it.

> What is wrong with adding in two bits of advice:
>
> (1) Because of the issue with RFC 2222, GSSAPI 2.1 implementations SHOULD
>      continue to act as if integ_req_flag is always set.
>
>      Since you said that this is how known GSSAPI 2.1 implementations
> work,
>      this doesn't change anything.

IMHO, imposing requirements on implementors of the GSS-API is out of scope 
for this working group.  Perhaps the chairs would care to comment?

> (2) RFC 2222 implementors MUST take note of the new requirement to set
>      integ_req_flag, and MUST upgrade their implementations.  Although all
>      known GSSAPI 2.1 implementations treat it as set, this behavior can
>      not be relied upon.

RFC 2222 is immutable.  To say "RFC 2222 implementors MUST..." is 
nonsensical.  Implementors of _this_ spec already MUST set the flag, and 
anything that's not an implementation of this spec is not subject to the 
requirement anyway.

I would not object to non-normative text to the effect that because RFC 
2222 was based on an older version of the GSS-API spec, implementations of 
this mechanism as described in RFC 2222 might not be setting integ_req_flag.

>> In
>> particular, without this requirement, it would be possible for a
>> "correct",  compliant implementation to fail to interoperate.  That
>> would be wrong, so we  must avoid it.
>
> What is the scenario that you envision?
>
> I'm worried about the scenario of a RFC 2222 compliant implementation
> failing to interoperate.

Well, if that happens, nothing we can say here is going to prevent it. 
Failing to set the flag may result in GSS_Wrap breaking.  If so, nothing we 
can do at the SASL layer will change that.  If not, it's going to work 
anyway.

-- Jeff

From: Martin Rex <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to
To: [email-masked] (Jeffrey Hutzelman)
Date: Tue, 29 Aug 2006 23:28:54 +0200 (MET DST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Jeffrey Hutzelman wrote:
> 
> Right.  RFC2743 makes it quite clear that callers which do not set 
> integ_req_flag may not be able to make use of integrity services.  It also 
> addresses the interoperability issues with applications written against 
> older versions of the API, recommending that mechanisms behave as if the 
> flag were set when the caller is known to be using the old API.

There seems to be a misunderstanding about the "conf_req_flag" and
"integ_req_flags".

The only reason why these flags were added to GSS-API v2(u1) was to
enable negotiating mechanisms (=SPNEGO) to consider them when
making a choice for the most appropriate common gssapi mechanism.

It was NOT intended to be a requirement for the initiator to assert
these flags as a general prerequisite in order to use the message
protection services.  Keep in mind that the acceptor still doesn't
have the opportunity to indicate such "requirements", so the
gssapi mechanism must always assume that the acceptor wants them.

The absence of the request for message protection services may
result in a negotiating mechanism to negotiate a mechanism that
doesn't have message protection services (based on its configured
preference), although there might have been a common gssapi mechanism
that would have provided such services (and which would have been
preferred if the initiator had asserted these flags).

A gssapi mechanism that implements message protection services
but refuses them if the newly added "conf_req_flag" and "integ_req_flag"
weren't passed in during gss_init_sec_context() must be considered
seriously broken.

-Martin

Date: Tue, 29 Aug 2006 17:21:43 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Mark Crispin <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040406050102000805040203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Mark Crispin wrote:

> What is wrong with adding in two bits of advice:
> 
> (1) Because of the issue with RFC 2222, GSSAPI 2.1 implementations SHOULD
>     continue to act as if integ_req_flag is always set.
> 
>     Since you said that this is how known GSSAPI 2.1 implementations work,
>     this doesn't change anything.
> 
> (2) RFC 2222 implementors MUST take note of the new requirement to set
>     integ_req_flag, and MUST upgrade their implementations.  Although all
>     known GSSAPI 2.1 implementations treat it as set, this behavior can
>     not be relied upon.
> 

Mark,

does the text proposed by Sam Hartman meet your needs?

if so, can we reach consensus on that text and move on?

Jeffrey Altman

--------------ms040406050102000805040203
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040406050102000805040203--

Date: Tue, 29 Aug 2006 17:07:37 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Mark Crispin <[email-masked]>, Sam Hartman <[email-masked]>
cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:01+jvtpWSjYhlGhmUmLbkdFJGtJNCBb2ZnsBsKMLs=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, August 29, 2006 01:11:06 PM -0700 Mark Crispin 
<[email-masked]> wrote:

>
> Modulo the 2078/1522 difference, this proposed addition is OK with me.
>
> I'm curious, though, why did RFC 2743 make integrity protection optional?
> What benefit is gained?

It didn't.  It's always been the case that any given mechanism may or may 
not provide integrity protection and/or confidentiality.  What RFC2743 did 
was to provide a means for applications to signal at context establishment 
time which features they would be using.  Depending on the mechanism, that 
might affect what happens during the initial negotiation.

This is particularly interesting because some applications may never intend 
to use the GSS-API's integrity or confidentiality services.  They may 
instead use channel bindings to associate the context to some lower-layer 
channel like TLS or IPsec, or use the recently-defined PRF operation to 
obtain keying material for some application-specific purpose.

> How does RFC 2222 compliant software know that it is in a RFC 2743 world?

That's a tricky question.  On the one hand, RFC 2222 compliant software is 
"obviously" using RFC 2078, since that is what is specified.  Note that 
both RFC 2078 and RFC 2743 are "abstract" interfaces; things like 
compilation, and in fact anything language-specific, are out of their scope.

Now, in the real world, of course you're going to find yourself compiling 
and linking against RFC 2743/2744 implementations.  Unfortunately, the C 
bindings for GSS-API are deficient in that they don't provide a defined way 
to tell what version of the API is being provided.  However, you can 
probably do things like test whether GSS_C_INTEG_FLAG is defined, and use 
it if so.  But be careful -- I could find nothing in RFC2744 which requires 
this to be a preprocessor macro as opposed to an enumerated type value or a 
global variable.

-- Jeff

Date: Tue, 29 Aug 2006 17:06:36 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed updates for domain-based drafts
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040607010709050700090101
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Nico,

Thank you for writing this summary.  I am going to extend the WGLC for
one week in order to provide time for specific text to be proposed and
for consensus to be reached.

Jeffrey Altman
Kitten Chair

Nicolas Williams wrote:
> Issues that came up:
> 
>  - Sam wanted a better outline of how applications might use
>    domain-based names.  I'm not sure whether Sam wants text for the
>    drafts or merely discussion on the list.
> 
>  - Sam and Jeff H. were concerned about the SASL framework vis-a-vis
>    domain-based names.
> 
>  - Jeff Hutzelman wanted
> 
>     - A clarification on just what is a "domain"
> 
>     - A new feature in the Kerberos V GSS-API mechanism relating to
>       domain-based names: initiator-side fallback on hostbased naming
>       with domainnames as hostnames with acceptor-side acceptor
>       credential sharing.
> 
> 
> To address Sam's main comment I propose re-writing the introduction to
> explain that domain-based names are intended to provide protection to
> applications utilizing insecure service discovery methods.  Additionally
> the specification of what domainname to be used in the domain part of
> domain-based names will be left to applications.  Some applications may
> use SRV RR names as domainnames (e.g., _tcp._foosvc.example.com), others
> may use plain domainnames (e.g., example.com).  Finally, I propose a new
> section containing Informative descriptions of how NFSv4 and LDAP
> clients (ignoring SASL naming issues; see below) would perform service
> discovery using DNS SRV RR queries and domain-based service names for
> servers named in the SRV RRs.  I will send text tonight, hopefully.
> 
> With respect to SASL I believe there is nothing for either of these two
> I-Ds to say on the matter.  I believe applications and SASL/GS1 and/or
> SASL/GS2 will require updating to specify use of domain-based names in
> SASL contexts.  I don't believe that we absolutely must update the SASL
> base specification to introduce new kinds of server names, but I don't
> mind us doing so -- either way the I-Ds we're considering in this WGLC
> are unaffected.
> 
> After some off-line discussion with Jeff about his proposed new feature
> we reached a compromise.  We propose the following change to
> draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt:
> 
> -   GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal
> -   names as follows:
> +   GSS_C_NT_DOMAINBASED_SERVICE name SHOULD be mapped to Kerberos V
> +   principal names as follows:
> 
> This will allow for a future document that specifies Jeff's fallback
> feature.
> 
> Nico

--------------ms040607010709050700090101
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040607010709050700090101--

Date: Tue, 29 Aug 2006 13:57:28 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
> Right.  RFC2743 makes it quite clear that callers which do not set 
> integ_req_flag may not be able to make use of integrity services.  It also 
> addresses the interoperability issues with applications written against older 
> versions of the API, recommending that mechanisms behave as if the flag were 
> set when the caller is known to be using the old API.

Can you elaborate on "when the caller is known to be using the old API"?

How does my RFC 2222 compliant caller identify itself as using the old 
API (or the new API)?

As far as I know, the only thing that I needed to do to become compliant 
with the new draft was to add GSS_C_INTEG_FLAG to the other flags in the 
6th argument to gss_init_sec_context().  Does that change my application 
from an old API to a new API?

> Right.  If your SASL implementation is written against a GSS-API v1 library, 
> then you have nothing to worry about, because that flag did not exist then. 
> If you have been linking it against a v2 library, then you had to deal with 
> the API changes in v2, and if you failed to not that you needed to set 
> integ_req_flag, then that is your own problem.

Say what???

I have no idea what version of GSSAPI I implemented against.  I followed 
the instructions in RFC 2222.

I look in my /usr/kerberos/include/gssapi/gssapi.h and see that there is a 
GSS_C_INTEG_FLAG defined with the other flags that can be supplied to the 
6th argument to gss_init_sec_context.  I assume, in good faith, that that 
is what you are talking about when you say "integ_req_flag"; just like I 
assume, in good faith, that the gss_init_sec_context() function is what 
you are talking about when you refer to GSS_Init_sec_context.

If now you're saying me that this is all something different, then what on 
earth are you talking about?  There is no "integ_req_flag" or 
"GSS_Init_sec_context".

If this is the "old API", then how does it have GSS_C_INTEG_FLAG if it is 
not in the "old API"?  If this is the "new API", then how does my code, 
written to comply with RFC 2222, build under it?

Last but not least, why is it my problem that I didn't do something that 
the (still current) specification never said that I had to do?

 	"But Mr. Dent, the plans have been available in the local planning
 	office for the last nine months."
 	"On display?  I eventually had to go down to the cellar to find
 	them...It was on display in the bottom of a locked filing cabinet
 	stuck in a disused lavatory with a sign on the door saying 'Beware
 	of the Leopard.'"

> Since this version of the SASL GSSAPI mechanism is being updated to use a new 
> version of the GSS-API, it is appropriate and necessary to update it to 
> reflect new requirements placed on the users of that API.  Note that even if 
> the new document were silent on this issue, you would _still_ be required to 
> set the flag if you wanted integrity services to work, because that is a 
> requirement of RFC2743.  The language we're arguing about is intended to make 
> that clear to implementors of this mechanism.

I don't want (or not want) integrity services to work.

I want the GSSAPI SASL mechanism to work; that is, to authenticate to a 
Kerberos 5 server.  All I knew of integity services was the optional part 
for privacy and integrity in SASL which I wasn't using -- meaning that, as 
far as I knew, this did not apply to me.

Now you tell me that it does, and that it's all my fault for making the 
false assumption that I had integrity when I did not.  The problem with 
that is that it assumes that I, implementing from RFC 2222, knew enough 
about the internals of GSSAPI to make that kind of assumption.

RFC 2222 goes to great efforts to hide what GSSAPI does.  If it didn't, I 
doubt very much that I would use GSSAPI instead of doing the Kerberos 
protocol myself.  That way, I wouldn't have to deal with surprises like 
"You must set this bit when you call GSSAPI.  True, we didn't tell you 
about it back then, but it's still your fault for not knowing about it."

> Yes, depending on the GSS-API krb5 mechanism implementation, setting or not 
> setting the integ_req_flag might result in a change to the bit in the wire 
> protocol which conveys the request from initiator to acceptor.  However, 
> there is no additional negotiation or setup involved, and the Wrap/Unwrap and 
> GetMic/VerifyMIC operations defined in RFC4121 (and RFC1964) work regardless 
> of the value of this flag.

I don't quite understand this, but will assume that the next paragraph 
explains it:

> An RFC2222 implementation using GSS-API v1 will work just fine.
> An RFC2222 implementation using GSS-API v2.1 with integ_req_flag will work.
> An RFC2222 implementation using GSS-API v2.1 without integ_req_flag is 
> already wrong, but probably works anyway.

What is "an RFC2222 implementation...with integ_req_flag"?  RFC 2222 is 
silent on the matter.

Doesn't the addition of integ_req_flag upgrade an RFC 2222 implementation 
to RFC xxxx (where xxxx is whatever number gets assigned to this new 
document)?

If it does not upgrade the implementation from RFC 2222 to RFC xxxx (I 
read the draft and I didn't see any other matter that call for a change), 
why not and what else do I need to do?

> A different GSS-API v2.1 library 
> would be entirely within its rights to make it not work, under the existing 
> GSS-API specification.  RFC2222, RFC4422, and this spec have nothing to do 
> with it.

I strongly disagree.  Either this is a bug in RFC 2222, or is an 
incompatibility in GSSAPI 2.1 that broke RFC 2222.  Either way, it is not 
a good thing that this came to pass, and the innocent implementors who 
followed RFC 2222 are not to blame for the situation.

> A new implementation of RFC4422 and this spec would need to comply with the 
> requirements of RFC2743, including the need to set integ_req_flag if it wants 
> integrity services.  An implementation that failed to do so would be 
> noncompliant, but would probably work anyway; however, it would be entirely 
> within the rights of an GSS-API v2.1 Kerberos mechanism implementation to 
> break this.

If this is so, do you agree that this is an incompatible (and unfortunate) 
change in GSSAPI 2.1?

What is wrong with adding in two bits of advice:

(1) Because of the issue with RFC 2222, GSSAPI 2.1 implementations SHOULD
     continue to act as if integ_req_flag is always set.

     Since you said that this is how known GSSAPI 2.1 implementations work,
     this doesn't change anything.

(2) RFC 2222 implementors MUST take note of the new requirement to set
     integ_req_flag, and MUST upgrade their implementations.  Although all
     known GSSAPI 2.1 implementations treat it as set, this behavior can
     not be relied upon.

I don't think that this is that much to ask; and I think that this 
accomplishes the goals that you set out to accomplish.

>In 
> particular, without this requirement, it would be possible for a "correct", 
> compliant implementation to fail to interoperate.  That would be wrong, so we 
> must avoid it.

What is the scenario that you envision?

I'm worried about the scenario of a RFC 2222 compliant implementation 
failing to interoperate.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 29 Aug 2006 15:57:24 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Proposed updates for domain-based drafts
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Issues that came up:

 - Sam wanted a better outline of how applications might use
   domain-based names.  I'm not sure whether Sam wants text for the
   drafts or merely discussion on the list.

 - Sam and Jeff H. were concerned about the SASL framework vis-a-vis
   domain-based names.

 - Jeff Hutzelman wanted

    - A clarification on just what is a "domain"

    - A new feature in the Kerberos V GSS-API mechanism relating to
      domain-based names: initiator-side fallback on hostbased naming
      with domainnames as hostnames with acceptor-side acceptor
      credential sharing.

To address Sam's main comment I propose re-writing the introduction to
explain that domain-based names are intended to provide protection to
applications utilizing insecure service discovery methods.  Additionally
the specification of what domainname to be used in the domain part of
domain-based names will be left to applications.  Some applications may
use SRV RR names as domainnames (e.g., _tcp._foosvc.example.com), others
may use plain domainnames (e.g., example.com).  Finally, I propose a new
section containing Informative descriptions of how NFSv4 and LDAP
clients (ignoring SASL naming issues; see below) would perform service
discovery using DNS SRV RR queries and domain-based service names for
servers named in the SRV RRs.  I will send text tonight, hopefully.

With respect to SASL I believe there is nothing for either of these two
I-Ds to say on the matter.  I believe applications and SASL/GS1 and/or
SASL/GS2 will require updating to specify use of domain-based names in
SASL contexts.  I don't believe that we absolutely must update the SASL
base specification to introduce new kinds of server names, but I don't
mind us doing so -- either way the I-Ds we're considering in this WGLC
are unaffected.

After some off-line discussion with Jeff about his proposed new feature
we reached a compromise.  We propose the following change to
draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt:

-   GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal
-   names as follows:
+   GSS_C_NT_DOMAINBASED_SERVICE name SHOULD be mapped to Kerberos V
+   principal names as follows:

This will allow for a future document that specifies Jeff's fallback
feature.

Nico
-- 

Date: Tue, 29 Aug 2006 13:11:06 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

Modulo the 2078/1522 difference, this proposed addition is OK with me.

I'm curious, though, why did RFC 2743 make integrity protection optional? 
What benefit is gained?

How does RFC 2222 compliant software know that it is in a RFC 2743 world? 
Does the compilation fail?  Or does it mysteriously stop working, maybe?

On Tue, 29 Aug 2006, Sam Hartman wrote:
> If that's OK, I propose the following text be added to the differences
> from RFC 2222:
> RFC 1508 specifies the version of GSS-API used by RFC 2222, which
> provided the original version of this specification.  That version of
> GSS-API did not provide the integ_integ_avail flag as an inpet to
> gss_init_sec_ctx.  Instead, integrity was always requested.  RFc 4222
> requires that when possible, the security layer negotiation be
> integrity protected.  To meet this requirement and as part of moving
> from RFC 1508 to RFC 2743, this specification requires that clients
> request integrity from gss_init_sec_ctx so they can use gss_wrap to
> protect the security layer negotiation.  This specification does not
> require that the mechanism offer the integrity security layer, simply
> that the security layer negotiation be wrapped.
>

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 29 Aug 2006 15:14:19 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>, Mark Crispin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Originator-Info: login-token=Mulberry:011a+IGD8X/Ywh+gCZCC24h2whv0Nc4wFCJLZ9Cy8=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, August 28, 2006 09:27:07 PM -0400 Sam Hartman 
<[email-masked]> wrote:

>     >> I required this change from the working group and do not think
>     >> I'm willing to take the document to the IESG unless integ_flag
>     >> remains a must.
>
>     Mark> Can we do some sort of compromise, such as these
>     Mark> stipulations:
>
>     Mark> All new client implementations MUST set integ_flag.
>
>     Mark> RFC 2222 implementations were not required to set
>     Mark> integ_flag.  This was based upon an implicit assumption that
>     Mark> clients could assume integrity even when not explicitly
>     Mark> requested.  This assumption is hereby deprecated.
>
> Actually, the change is in updating from RFC 1509 to RFC 2743.  RFC
> 1509 against which 2222 was written did not provide integ_flag.

Right.  RFC2743 makes it quite clear that callers which do not set 
integ_req_flag may not be able to make use of integrity services.  It also 
addresses the interoperability issues with applications written against 
older versions of the API, recommending that mechanisms behave as if the 
flag were set when the caller is known to be using the old API.

[ For the record, RFC2222 references RFC2078, not 1509.  But it appears 
that the integ_req_flag and conf_req_flag bits were not defined for 
GSS_Init_sec_context until GSS-API v2.1. ]

> The IETF does make incompatible changes when there is a reason to do
> so.  Fixing a security problem seems like a good reason to me.
> Integrity protection of the security layer parameters is really
> important and is a MUST in RFC 4222.  Personally, if I had to choose
> between breaking a few old implementations and making it sure that
> security worked, I would do so.
>
> But I don't think we're making that choice.  I think setting the
> integ_flag is an important change in upgrading an application from RFC
> 1509 to RFC 2743.

Right.  If your SASL implementation is written against a GSS-API v1 
library, then you have nothing to worry about, because that flag did not 
exist then.  If you have been linking it against a v2 library, then you had 
to deal with the API changes in v2, and if you failed to not that you 
needed to set integ_req_flag, then that is your own problem.

Since this version of the SASL GSSAPI mechanism is being updated to use a 
new version of the GSS-API, it is appropriate and necessary to update it to 
reflect new requirements placed on the users of that API.  Note that even 
if the new document were silent on this issue, you would _still_ be 
required to set the flag if you wanted integrity services to work, because 
that is a requirement of RFC2743.  The language we're arguing about is 
intended to make that clear to implementors of this mechanism.

>  Besides that, with the Kerberos mechanisms, I
> believe that it tends not to result in a wire change.  If it does
> result in a wire change it changes a flag bit in the RFC 1964 header.

Yes, depending on the GSS-API krb5 mechanism implementation, setting or not 
setting the integ_req_flag might result in a change to the bit in the wire 
protocol which conveys the request from initiator to acceptor.  However, 
there is no additional negotiation or setup involved, and the Wrap/Unwrap 
and GetMic/VerifyMIC operations defined in RFC4121 (and RFC1964) work 
regardless of the value of this flag.

In short...

An RFC2222 implementation using GSS-API v1 will work just fine.
An RFC2222 implementation using GSS-API v2.1 with integ_req_flag will work.
An RFC2222 implementation using GSS-API v2.1 without integ_req_flag is 
already wrong, but probably works anyway.  A different GSS-API v2.1 library 
would be entirely within its rights to make it not work, under the existing 
GSS-API specification.  RFC2222, RFC4422, and this spec have nothing to do 
with it.

A new implementation of RFC4422 and this spec would need to comply with the 
requirements of RFC2743, including the need to set integ_req_flag if it 
wants integrity services.  An implementation that failed to do so would be 
noncompliant, but would probably work anyway; however, it would be entirely 
within the rights of an GSS-API v2.1 Kerberos mechanism implementation to 
break this.

Given that this is the first version of this mechanism based on GSS-API 
v2.1, and that version introduces new requirements upon its callers that 
were not present in previous versions of the GSS-API, we would be remiss if 
we did not pass those requirements on to implementations of this mechanism. 
In particular, without this requirement, it would be possible for a 
"correct", compliant implementation to fail to interoperate.  That would be 
wrong, so we must avoid it.

-- Jeff

From: Sam Hartman <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to	Proposed Standard (draft-ietf-sasl-gssapi)
Date: Tue, 29 Aug 2006 09:51:25 -0400
Sender: [email-masked]

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> Hmm, I didn't read the original message as supporting the
    Sam> option where a must was maintained and text was added.

    Sam> If that's OK, I propose the following text be added to the
    Sam> differences from RFC 2222:

It turns out RFc 2222 uses RFC 2078 not RFC 1508, but the comments
about the integ_req flag still apply as that flag was not available in
2078.

From: Sam Hartman <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to	Proposed Standard (draft-ietf-sasl-gssapi)
Date: Tue, 29 Aug 2006 00:00:02 -0400
Sender: [email-masked]

[Jeff points out that I may have misread Mark's response.]

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

    Jeffrey> Sam: This is an excellent response but I don't think it
    Jeffrey> addresses the choice he has requested.  He has asked
    Jeffrey> either for the MUST to be made a SHOULD or for text to be
    Jeffrey> added to the document explaining to SASL implementors why
    Jeffrey> they now need to specify the integ_flag.

Hmm, I didn't read the original message as supporting the option where
a must was maintained and text was added.

If that's OK, I propose the following text be added to the differences
from RFC 2222:

RFC 1508 specifies the version of GSS-API used by RFC 2222, which
provided the original version of this specification.  That version of
GSS-API did not provide the integ_integ_avail flag as an inpet to
gss_init_sec_ctx.  Instead, integrity was always requested.  RFc 4222
requires that when possible, the security layer negotiation be
integrity protected.  To meet this requirement and as part of moving
from RFC 1508 to RFC 2743, this specification requires that clients
request integrity from gss_init_sec_ctx so they can use gss_wrap to
protect the security layer negotiation.  This specification does not
require that the mechanism offer the integrity security layer, simply
that the security layer negotiation be wrapped.

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Mon, 28 Aug 2006 21:27:07 -0400
Sender: [email-masked]

Hi.  This mesage is less organized than it should be.  It may be
easier to chat on the phone than to have too many more round trips
here.

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

    Mark> On Mon, 28 Aug 2006, Sam Hartman wrote:
    >> I don't think this change will create an interoperability
    >> problem.  gss_wrap only works if the context has integrity.  I
    >> believe that it is impossible for an implementation to
    >> interoperate with RFC 2222 or this spec unless integrity is
    >> available in the context as both this spec and RFC 2222 require
    >> gss_wrap to work.

    Mark> The "I believe" part scares me.

It's a really strong belief.
Factors that contribute to this belief:

* Neither RFC 2222 nor this spec  specify what to do if integrity protection is not available on a context.

* gss_wrap only works if integrity protection is available.

* The caller will call gss_unwrap on the input token.  There is no way
  under RFC 1964 nor RFC 4121 to produce  a token without integrity protection.

    >> I required this change from the working group and do not think
    >> I'm willing to take the document to the IESG unless integ_flag
    >> remains a must.

    Mark> Can we do some sort of compromise, such as these
    Mark> stipulations:

    Mark> All new client implementations MUST set integ_flag.

    Mark> RFC 2222 implementations were not required to set
    Mark> integ_flag.  This was based upon an implicit assumption that
    Mark> clients could assume integrity even when not explicitly
    Mark> requested.  This assumption is hereby deprecated.

Actually, the change is in updating from RFC 1509 to RFC 2743.  RFC
1509 against which 2222 was written did not provide integ_flag.

    Mark> Because RFC 2222 client authors were not warned about this
    Mark> implicit assumption, GSSAPI implementations MUST implicitly
    Mark> set integ_flag if the client does not set it.  [This renders
    Mark> the assumption into a MUST even though it is deprecated.]

No, I'm not willing to revisit this aspect of 2743 for a SASL
document.

    >> I am willing to listen to your arguments though and would be
    >> especially interested in cases where this change creates a wire
    >> protocol change.

    Mark> The thing is, I don't know.  There are multiple GSSAPI
    Mark> implementations. You're asking me to put faith that nothing
    Mark> will happen to cause an 8 year old RFC 2222 compliant
    Mark> implementation to break over the wire.

    Mark> I'm not trying to block the change; I'm just trying to
    Mark> ameliorate a potential bad consequence.

    Mark> Traditionally, the IETF has declined to break an installed
    Mark> base that was implemented in good faith.  I hope that this
    Mark> tradition is maintained.

The IETF does make incompatible changes when there is a reason to do
so.  Fixing a security problem seems like a good reason to me.
Integrity protection of the security layer parameters is really
important and is a MUST in RFC 4222.  Personally, if I had to choose
between breaking a few old implementations and making it sure that
security worked, I would do so.

But I don't think we're making that choice.  I think setting the
integ_flag is an important change in upgrading an application from RFC
1509 to RFC 2743.  Besides that, with the Kerberos mechanisms, I
believe that it tends not to result in a wire change.  If it does
result in a wire change it changes a flag bit in the RFC 1964 header.
I know that my implementation always forces this bit to be set
regardless of whether the user specifies the flag in the init_sec_ctx
API call.  So, I have high confidence that we would have noticed if
any SASL acceptors fail to work when that flag bit is set.

I think the only problem situation I can think of is an SASL server
that fails to work when the integ_avail flag is set in the first
context token but supports gss_wrap anyway.  That is, a SASL server
that supports integrity except when it is turned on, in which case it
fails.  That server seems quite broken to me.

A more serious problem case is a client that does not support gss_wrap
when integ_flag is not set in gss_init_sec_ctx.  I believe such a
client could not possibly work with RFC 2222 or this spec.  However I
think such a client is compatible with GSS-API.

In conclusion, I'm not at all sure what the possible behaviors are
when integ_flag is not set.  By far the most common behavior seems to
be working just fine.  The second likely behavior seems to be failing
to interoperate at all.  It also seems possible that someone would
manage to provide an implementation that is insecure when integ_flag
is not set; I am unaware of such an implementation.

The interoperability story when integ_flag is set seems much
better--we know it's supposed to work and we have strong evidence it
works in practice from interoperability events.  Everything that has
successfully tested against an MIT client will work fine.  Everything
that has been in one of the Kerberos interoperability events will work
fine.  Every server that supports integrity at the GSS-API layer will
work fine.  If you accept and ignore the integrity flag when you don't
support it (this is the standard GSS-API behavior), you will ork fine.
The failure case I can think of is a server that actually supports
integrity but claims not to support integrity and rejects the
connection when integ_avail is set.

I will choose avoiding more realistic interoperability problems and
the unlikely but possible unprotected security layer exchange to
avoiding what seems to me like a very unlikely interoperability
problem caused by the spec change.

--Sam

Date: Mon, 28 Aug 2006 17:43:09 -0700
To: Mark Crispin <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 04:20 PM 8/28/2006, Mark Crispin wrote:
>On Mon, 28 Aug 2006, Kurt D. Zeilenga wrote:
>>I dislike such MUSTs.   An old client should be conformant
>>to the old specification.  A new client should be conformant
>>to the new specification.  The new specification should discuss
>>known interoperability problems between implementations of the new
>>and old specifications.  My understanding is that there are
>>no known interoperability problems to discuss.
>
>Doesn't that depend upon the GSSAPI implementation? 

As indicated by my comments, yes.

Kurt 

Date: Mon, 28 Aug 2006 16:20:24 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to   Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Kurt D. Zeilenga wrote:
> I dislike such MUSTs.   An old client should be conformant
> to the old specification.  A new client should be conformant
> to the new specification.  The new specification should discuss
> known interoperability problems between implementations of the new
> and old specifications.  My understanding is that there are
> no known interoperability problems to discuss.

Doesn't that depend upon the GSSAPI implementation?

> This I-D should note the change was made and why in the Changes
> Since RFC 2222 section.

I agree.

It should document the implicit assumption in RFC 2222 and deprecate it, 
so that people understand what is being talked about.

IMHO, it should also make this assumption mandatory in GSSAPI 
implementations (which in theory just preserves the status quo) that may 
be called by RFC 2222 implementations.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 16:14:19 -0700
To: Mark Crispin <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 03:21 PM 8/28/2006, Mark Crispin wrote:
>Can we do some sort of compromise, such as these stipulations:
>
>All new client implementations MUST set integ_flag.

I dislike such MUSTs.   An old client should be conformant
to the old specification.  A new client should be conformant
to the new specification.  The new specification should discuss
known interoperability problems between implementations of the new
and old specifications.  My understanding is that there are
no known interoperability problems to discuss.

This I-D should note the change was made and why in the Changes
Since RFC 2222 section.

Date: Mon, 28 Aug 2006 16:09:18 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Nicolas Williams wrote:
>>> I don't think this change will create an interoperability problem.
>>> gss_wrap only works if the context has integrity.  I believe that it
>>> is impossible for an implementation to interoperate with RFC 2222 or
>>> this spec unless integrity is available in the context as both this
>>> spec and RFC 2222 require gss_wrap to work.
>> The "I believe" part scares me.
> Are you kidding?

No, I am not kidding.  "I believe" implies "I don't know".

The past 30+ years of Internet protocol development history are littered 
with instances in which people *believed* (in good faith) that something 
was the case, convinced others to act (in good faith) on the presumption 
that those beliefs were correct.  Much later, those beliefs were proven 
incorrect.

Please lets get the wordsmithing right, so that we base our actions upon 
precise text in specifications rather than our beliefs!

Thank you!

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 16:04:53 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Nicolas Williams wrote:
> Your implementation would break regardless of what the new doc says, so
> Joe Mooch and you would lose if MIT did what you posit.

Yes, but the difference is that I can point at RFC 2222, and say that I 
comply with RFC 2222.  If you make a change to GSSAPI that breaks an RFC 
2222 compliant implementation of the GSSAPI SASL method, the onus is on 
you.

> It wouldn't break if your implementation followed the new spec, that's
> true, but your old implementation's compliance would hardly make Joe
> Mooch feel any better, particularly if MIT could claim compliance for
> the change that you posit.  You'd be on the hook either way.

Not at all, because my code complies with RFC 2222 and RFC 2222 says 
nothing about integ_flag.  As currently written, this change retroactively 
labels RFC 2222 compliant implementations as non-compliant.

Maybe my memory is faulty, but I can't recall a case where the IETF has 
done this to implementations written in good faith to older versions of 
the standards.  In fact, I remember an IETF that has bent over backwards 
to avoid doing such a thing, even to the point of absurdity (as can be 
seen in USEFOR and NNTPEXT).

> No existing GSS-API multi-mechanism library implementor should do what
> you posit.  Yes, it's possible, it's just not probable, not remotely
> probable, and, anyways, your claims of compliance would do nothing for
> your users.

I know from past experience that SUN objects vigorously when a proposal 
has the effect of putting it in such a position.  You shouldn't expect me 
to be sanguine.

All that is necessary is to document that:

1) RFC 2222 was silent on the matter of integ_flag.
2) RFC 2222 compliant implementations could have omitted integ_flag.
3) This worked because GSSAPI implementations implicitly set integ_flag
    even if omitted.
4) Clients that followed RFC 2222 assumed (3), but the implementors of
    those clients may not have known that they did so.
5) The ability of a client to assume (3) is deprecated.
6) To preserve RFC 2222 compatibility, GSSAPI implementations MUST do (3)
    even though its assumption is deprecated.
7) As a consequence of (5), RFC 2222 implementors are on notice to add
    integ_flag in updates.

Based upon what y'all have said, none of the above changes anyone's code, 
other than putting RFC 2222 implementors on notice that they need to add 
the setting of integ_flag.  I have already done so.

But it prevents a possible future problem, one you categorize as "not 
remotely probable".

If this is just a bit of wordsmithing and not a technical change, why not 
do it?  What purpose is served by creating a possible future problem that 
is "not remotely probable"?

Isn't the point of a Last Call to uncover such issues, and resolve them?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 17:50:00 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Aug 28, 2006 at 03:21:18PM -0700, Mark Crispin wrote:
> On Mon, 28 Aug 2006, Sam Hartman wrote:
> >I don't think this change will create an interoperability problem.
> >gss_wrap only works if the context has integrity.  I believe that it
> >is impossible for an implementation to interoperate with RFC 2222 or
> >this spec unless integrity is available in the context as both this
> >spec and RFC 2222 require gss_wrap to work.
> 
> The "I believe" part scares me.

Are you kidding?

Nico
-- 

Date: Mon, 28 Aug 2006 17:45:10 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Aug 28, 2006 at 03:33:45PM -0700, Mark Crispin wrote:
> On Mon, 28 Aug 2006, Nicolas Williams wrote:
> >>>Since this is all specific to the Kerberos V GSS-API mechanism I think
> >>>the value of this flag is irrelevant, so this change should not render
> >>>any earlier implementations non-compliant in terms of their on-the-wire
> >>>behaviour.
> >>In that case, it's all the more reason to use SHOULD instead of MUST.
> >Why?  MUST would be correct and happens not to break earlier
> >implementations.  What's the downside?  I don't see any.  See below.
> 
> Joe Mooch GSSAPI replaces MIT GSSAPI.  Mooch GSSAPI suddenly breaks all my 
> installations.
> 
> Joe Mooch points the finger of blame on me for not following a 
> specification that was issued years *AFTER* the code was released.

Your implementation would break regardless of what the new doc says, so
Joe Mooch and you would lose if MIT did what you posit.

It wouldn't break if your implementation followed the new spec, that's
true, but your old implementation's compliance would hardly make Joe
Mooch feel any better, particularly if MIT could claim compliance for
the change that you posit.  You'd be on the hook either way.

No existing GSS-API multi-mechanism library implementor should do what
you posit.  Yes, it's possible, it's just not probable, not remotely
probable, and, anyways, your claims of compliance would do nothing for
your users.

> But the problem is that if this were to pass, the egg would be on my face, 
> even though I implemented RFC 2222 in good faith according to the 
> specification.

I don't agree.

Nico
-- 

Date: Mon, 28 Aug 2006 15:33:45 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Nicolas Williams wrote:
>>> Since this is all specific to the Kerberos V GSS-API mechanism I think
>>> the value of this flag is irrelevant, so this change should not render
>>> any earlier implementations non-compliant in terms of their on-the-wire
>>> behaviour.
>> In that case, it's all the more reason to use SHOULD instead of MUST.
> Why?  MUST would be correct and happens not to break earlier
> implementations.  What's the downside?  I don't see any.  See below.

Joe Mooch GSSAPI replaces MIT GSSAPI.  Mooch GSSAPI suddenly breaks all my 
installations.

Joe Mooch points the finger of blame on me for not following a 
specification that was issued years *AFTER* the code was released.

>> However, a change in the GSSAPI shared library could, without change to
>> the client code itself, render a client that fails to set integ_req_flag
>> non-compliant over-the-wire.  So we shouldn't count upon this.
> I think that would be really wrong on the part of the implementor

That's the problem.

I've had 30+ years of bad experience with "it would be really wrong [so 
don't worry about it happening]" that subsequently happened and caused 
horrendous problems.

> but
> even assuming it's possible I really doubt that this could happen to old
> implementations of the SASL "GSSAPI" mechanism, and if it did and they
> had not set integ_req_flag == TRUE then they would, in fact, fail to
> operate.

But the problem is that if this were to pass, the egg would be on my face, 
even though I implemented RFC 2222 in good faith according to the 
specification.

The IETF once had a tradition of not pulling the rug out from implementors 
who followed the specification in good faith.  Is this now abolished?

> Protocol-wise this change is a no-op, so I fail to see how old
> implementations become non-compliant -- you'd have to trace their
> execution to determine that they are non-compliant w.r.t. API use.

That MAY be the case with the GSSAPI implementations that are KNOWN to you 
(and me).  But there is no surety that this is, or will be, the case.

I agree that there seems to be no technical problem now; but can't we 
PLEASE come up with suitable wordsmithing to preclude possible problems in 
the future?

If RFC 2222 compatibility can not be maintained, then please change the 
mechanism name to GSSAPIrev1 so that any negotiation using the name GSSAPI 
will be known to comply with RFC 2222.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 15:21:18 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Sam Hartman wrote:
> I don't think this change will create an interoperability problem.
> gss_wrap only works if the context has integrity.  I believe that it
> is impossible for an implementation to interoperate with RFC 2222 or
> this spec unless integrity is available in the context as both this
> spec and RFC 2222 require gss_wrap to work.

The "I believe" part scares me.

> The reason most everything works in practice is that GSS
> implementations tend to provide integrity even when it is not
> explicitly requested.

I implemented according to RFC 2222.  RFC 2222 did not require integ_flag 
to be set, and was silent on the issue.

Upon seeing the Last Call, I saw this change (which I did not see listed 
as being a change from RFC 2222), and made the change to the development 
version my code.  But this does not change the installed base.

> I required this change from the working group and do not think I'm
> willing to take the document to the IESG unless integ_flag remains a
> must.

Can we do some sort of compromise, such as these stipulations:

All new client implementations MUST set integ_flag.

RFC 2222 implementations were not required to set integ_flag.  This was 
based upon an implicit assumption that clients could assume integrity even 
when not explicitly requested.  This assumption is hereby deprecated.

Because RFC 2222 client authors were not warned about this implicit 
assumption, GSSAPI implementations MUST implicitly set integ_flag if the 
client does not set it.  [This renders the assumption into a MUST even 
though it is deprecated.]

> I am willing to listen to your arguments though and would be
> especially interested in cases where this change creates a wire
> protocol change.

The thing is, I don't know.  There are multiple GSSAPI implementations. 
You're asking me to put faith that nothing will happen to cause an 8 year 
old RFC 2222 compliant implementation to break over the wire.

I'm not trying to block the change; I'm just trying to ameliorate a 
potential bad consequence.

Traditionally, the IETF has declined to break an installed base that was 
implemented in good faith.  I hope that this tradition is maintained.

I also hope that we are not in technical disagreement, just in 
wordsmithing.

Thanks,

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 17:08:20 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Aug 28, 2006 at 02:54:51PM -0700, Mark Crispin wrote:
> On Mon, 28 Aug 2006, Nicolas Williams wrote:
> >Since this is all specific to the Kerberos V GSS-API mechanism I think
> >the value of this flag is irrelevant, so this change should not render
> >any earlier implementations non-compliant in terms of their on-the-wire
> >behaviour.
> 
> In that case, it's all the more reason to use SHOULD instead of MUST.

Why?  MUST would be correct and happens not to break earlier
implementations.  What's the downside?  I don't see any.  See below.

> >(At least one implementation of the Kerberos V GSS mechanism used to
> >leave out confidentiality protection, but none, to my knowledge, fails
> >to provide MIC and/or wrap tokens when integ_req_flag == false in the
> >call to GSS_Init_sec_context().)
> 
> However, a change in the GSSAPI shared library could, without change to 
> the client code itself, render a client that fails to set integ_req_flag 
> non-compliant over-the-wire.  So we shouldn't count upon this.

I think that would be really wrong on the part of the implementor, but
even assuming it's possible I really doubt that this could happen to old
implementations of the SASL "GSSAPI" mechanism, and if it did and they
had not set integ_req_flag == TRUE then they would, in fact, fail to
operate.

> I just don't want a path where my old installed base is retroactively 
> declared non-compliant, or a trap laid where external events could change 
> that base to become non-compliant.  It's an entirely different matter if 
> the old code is not "non-compliant" but has (potential) behavior that is 
> "deprecated" in favor of the new code which follows the new rule.

Protocol-wise this change is a no-op, so I fail to see how old
implementations become non-compliant -- you'd have to trace their
execution to determine that they are non-compliant w.r.t. API use.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi)
Date: Mon, 28 Aug 2006 18:03:16 -0400
Sender: [email-masked]

>>>>> "Mark" == Mark Crispin <[email-masked]> writes:

I don't think this change will create an interoperability problem.
gss_wrap only works if the context has integrity.  I believe that it
is impossible for an implementation to interoperate with RFC 2222 or
this spec unless integrity is available in the context as both this
spec and RFC 2222 require gss_wrap to work.

The reason most everything works in practice is that GSS
implementations tend to provide integrity even when it is not
explicitly requested.

I required this change from the working group and do not think I'm
willing to take the document to the IESG unless integ_flag remains a
must.

I am willing to listen to your arguments though and would be
especially interested in cases where this change creates a wire
protocol change.
-

--Sam

Date: Mon, 28 Aug 2006 14:54:51 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 28 Aug 2006, Nicolas Williams wrote:
> Since this is all specific to the Kerberos V GSS-API mechanism I think
> the value of this flag is irrelevant, so this change should not render
> any earlier implementations non-compliant in terms of their on-the-wire
> behaviour.

In that case, it's all the more reason to use SHOULD instead of MUST.

> (At least one implementation of the Kerberos V GSS mechanism used to
> leave out confidentiality protection, but none, to my knowledge, fails
> to provide MIC and/or wrap tokens when integ_req_flag == false in the
> call to GSS_Init_sec_context().)

However, a change in the GSSAPI shared library could, without change to 
the client code itself, render a client that fails to set integ_req_flag 
non-compliant over-the-wire.  So we shouldn't count upon this.

I just don't want a path where my old installed base is retroactively 
declared non-compliant, or a trap laid where external events could change 
that base to become non-compliant.  It's an entirely different matter if 
the old code is not "non-compliant" but has (potential) behavior that is 
"deprecated" in favor of the new code which follows the new rule.

> GSS_C_NO_CHANNEL_BINDINGS is only defined in the C bindings of the
> GSS-API (RFC2744), whereas the base GSS-API specification (RFC2743) uses
> "NULL" to mean "no channel bindings" (e.g., "...where NULL channel
> bindings..." and "[w]hen non-NULL channel bindings are provided").

OK, consider that one withdrawn.  Thanks.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 28 Aug 2006 16:46:51 -0500
From: Nicolas Williams <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)
Mail-Followup-To: Mark Crispin <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Aug 28, 2006 at 01:39:42PM -0700, Mark Crispin wrote:
> 
> I request consideration of the following changes prior to publication.
> 
> Page 4, first paragraph, please change:
>    [...]  When calling the GSS_Init_sec_context the client
>    MUST pass the integ_req_flag of TRUE.
> to
>    [...]  When calling the GSS_Init_sec_context the client
>    SHOULD pass the integ_req_flag of TRUE.
> 
> Otherwise, publication of this document would have the effect of declaring 
> existing deployed software to be non-compliant.  I agree that this change 
> is desirable, but I disagree about retroactively declaring existing 
> software broken.  If the WG feels strongly enough, it'd be alright to have 
> something in the security considerations saying that earlier versions did 
> not require the integ_req_flag, but all new implementations ought to have 
> it and old implementations fixed.

Since this is all specific to the Kerberos V GSS-API mechanism I think
the value of this flag is irrelevant, so this change should not render
any earlier implementations non-compliant in terms of their on-the-wire
behaviour.

(At least one implementation of the Kerberos V GSS mechanism used to
leave out confidentiality protection, but none, to my knowledge, fails
to provide MIC and/or wrap tokens when integ_req_flag == false in the
call to GSS_Init_sec_context().)

> Suggested changes (this is just cosmetic):
> 
> Page 5, second paragraph, change
>    [...] chan_binding of NULL
> to:
>    [...] chan_binding of GSS_C_NO_CHANNEL_BINDINGS
> 
> Similarly for page 7 in the third paragraph of the Security 
> Considerations.

GSS_C_NO_CHANNEL_BINDINGS is only defined in the C bindings of the
GSS-API (RFC2744), whereas the base GSS-API specification (RFC2743) uses
"NULL" to mean "no channel bindings" (e.g., "...where NULL channel
bindings..." and "[w]hen non-NULL channel bindings are provided").

Nico
-- 

Date: Mon, 28 Aug 2006 13:39:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi) 
Organization: Networks & Distributed Computing
Sender: [email-masked]

I request consideration of the following changes prior to publication.

Page 4, first paragraph, please change:
    [...]  When calling the GSS_Init_sec_context the client
    MUST pass the integ_req_flag of TRUE.
to
    [...]  When calling the GSS_Init_sec_context the client
    SHOULD pass the integ_req_flag of TRUE.

Otherwise, publication of this document would have the effect of declaring 
existing deployed software to be non-compliant.  I agree that this change 
is desirable, but I disagree about retroactively declaring existing 
software broken.  If the WG feels strongly enough, it'd be alright to have 
something in the security considerations saying that earlier versions did 
not require the integ_req_flag, but all new implementations ought to have 
it and old implementations fixed.

Suggested changes (this is just cosmetic):

Page 5, second paragraph, change
    [...] chan_binding of NULL
to:
    [...] chan_binding of GSS_C_NO_CHANNEL_BINDINGS

Similarly for page 7 in the third paragraph of the Security 
Considerations.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to  Proposed Standard (draft-ietf-sasl-gssapi) 
Reply-To: [email-masked]
Cc: <[email-masked]>, [email-masked]
Date: Mon, 28 Aug 2006 16:18:14 -0400
Sender: [email-masked]

The IESG has received a request from the Simple Authentication and 
Security Layer WG to consider the following document:

- 'The Kerberos V5 ("GSSAPI") SASL mechanism '
   <draft-ietf-sasl-gssapi-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-09-11.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-07.txt

Date: Fri, 25 Aug 2006 22:15:39 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and
Mail-Followup-To: Martin Rex <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Sat, Aug 26, 2006 at 01:58:19AM +0200, Martin Rex wrote:
> The text I didn't like talks about "what the server supports", but that
> is inappropriate when talking about the target_name used by the initiator.

OK, it really should be something like "what the server has acceptor
credentials for."

> Now if the client is using a different SPKM implementation that
> implement GSS_C_NT_HOSTBASED_SERVICE and performs some sort of
> endpoint identification (instead of an authentication) as proposed for 
> SPKM3, then you would have the situation that the server doesn't
> support hostbased service names, and still the client might succeed
> in using it.

Because it has credentials that authenticate the hostbased service that
the client wanted.  The details of how that happens are not relevant
here.

> In a different (Kerberos-based) installation, an SSH-Server might be running
> with a hostbased service name and a special ssh/hostabc.f.q.d.n principal
> and a service mapping function ssh@somehost -> ssh/somehost.f.q.d.n
> [...]

A server that did this could not interoperate with a client that merely
followed RFC4462 and didn't provide an option by which the user could
provide an alternate service name.

This is why it's important for our specifications to tell us about
acceptor naming.

Even if the Kerberos V GSS-API mechanism allowed the acceptor to tell
the initiator what its name is (and we could define a new version of the
krb5 mechanisms, with a new OID, that did this), the client would still
have to know to use GSS_C_NO_NAME and then tell the user what name was
authenticated and ask if that's OK, or otherwise authorize the
authenticated acceptor name to the actual server/whatever name provided
by the client.  These are instructions that have to be provided by the
application protocol specific for at the common mode of operation,
otherwise we can't have interop.

> So whether a hostbased service name can be used depends primarily on
> 
> (a) does the initiators gssapi mechanism implementation implement
>     this nametype
> 
> (b) does the initiators gssapi mechanism implementation's service
>     mapping function transform a given hostbased service name to
>     the correct principal name as used by the server (this might be
>     a local configuration issue).

(c) does the acceptor have acceptor credentials for that name.  This is
important for mechanisms which, as you point out repeatedly, don't allow
the initiator to discover the acceptor's name instead of having to
always provide it upfront.

Tough.  Kerberos V is the interoperable mechanism we have, and hostbased
service naming is the interoperable form of server naming.  Can we go
beyond this?  SASL/GS1 is not going to depart from hostbased service
naming as the minimum requirement and common name type for
interoperability -- though we may add more.

Nico
-- 

Date: Fri, 25 Aug 2006 15:27:39 -0500
From: Nicolas Williams <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and
Mail-Followup-To: Martin Rex <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Fri, Aug 25, 2006 at 07:56:33PM +0200, Martin Rex wrote:
> There seems to be a significant misunderstanding in how GSS-API works.

I interpret your post as saying, in so many words, that the right thing
to do is to speak of "host-based service" not the specific name type
GSS_C_NT_HOSTBASED_SERVICE in prescribing what an initiator application
ought to do, since, after all, the application could use
mechanism-specific equivalents.

Is that correct?

If so I agree but I am not sure that I care.  Perhaps if you suggested
new text?

Nico
-- 

Date: Fri, 25 Aug 2006 15:51:37 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>
cc: [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Originator-Info: login-token=Mulberry:01252gS0UFFb8n6BjMDhvQunIP13Zi0RlIEs6wER0=; token_authority=[email-masked]
Sender: [email-masked]

On Friday, August 25, 2006 06:24:45 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>
> I believe I've addressed all the points you've raised.
>
> The only change I haven't made is adding some text about verifying
> security flags once the context is established. Please let me know if
> such text should be added.

Well, I think Nico's argument is that you don't need to check the context 
flags because you can determine the same information from the results of 
calling GSS_Wrap.  That's true, but only if you check the results of 
GSS_Wrap, an in particular, if we are supposed to be providing 
confidentiality, check that the conf_state returned by GSS_Wrap is true.

Personally, section 3.3 looks more like an outline than a protocol 
specification to me.  The entire description of the security layer 
providing confidentiality protection is the single phrase

  "Sender calls GSS_Wrap with conf_flag set to TRUE"

It doesn't describe the values of other parameters to GSS_Wrap, checking of 
return status, what happens if the call fails, or what is done with the 
resulting token.  It doesn't describe _anything_ about what the receiver of 
such a token is supposed to do.

-- Jeff

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-gssapi-07.txt 
Date: Fri, 25 Aug 2006 15:50:02 -0400
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		: The Kerberos V5 ("GSSAPI") SASL mechanism
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-gssapi-07.txt
	Pages		: 10
	Date		: 2006-8-25
	
The Simple Authentication and Security Layer (SASL, RFC 4422) is a
framework for adding authentication support to connection-based
protocols.  This document describes the method for using the Generic
Security Service Application Program Interface (GSS-API) Kerberos V5
in the SASL.

This document replaces section 7.2 of RFC 2222, the definition of the
"GSSAPI" SASL mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gssapi-07.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-gssapi-07.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-gssapi-07.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-gssapi-07.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 25 Aug 2006 18:24:45 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

I believe I've addressed all the points you've raised.

The only change I haven't made is adding some text about verifying 
security flags once the context is established. Please let me know if 
such text should be added.

Date: Fri, 25 Aug 2006 18:16:12 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Aug 23, 2006 at 12:54:36PM -0400, Sam Hartman wrote:
>  
>
>>And so I'd prefer it be non-normative.  The normative requirement
>>should be stated in terms of the SASL mechanism: The client MAY use
>>another name type if it knows the server will support it.
>>    
>>
>
>Sure.
>  
>
Ok, I've added the following text:
   Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to
   import servers' acceptor names, but only when they have a priori
   knowledge that the servers support alternate name types.  Otherwise
   clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
   names.

I.e. I removed the last sentence you've proposed.

Date: Thu, 24 Aug 2006 18:00:25 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Kitten <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Aug 23, 2006 at 11:44:59AM +0100, Alexey Melnikov wrote:
>  
>
>>Jeffrey Altman wrote:   
>>
>>>                            The question then appears to me to be more
>>>general than the question of whether or not SASL-GSS-1 or SASL-GSS-2
>>>must be updated.  Instead it appears to be "does SASL support the
>>>concept of authentication with domain-based names at all?"
>>>      
>>>
>>When integrating SASL into SMTP, IMAP and LDAP servers I always assumed 
>>that the answer to this question was "yes".
>>    
>>
>Well, RFC4422 does require that a service name always be involved
>(section 4, item (1)).
>
Yes, however mechanisms are free not to use it and many mechanisms don't.

>But it doesn't actually discuss the structure of
>server names -- it doesn't even mention hostnames or domainnames.
>  
>
I think this is a mechanism specific issue. But I might be convinced 
that I am wrong.

Anyway, I think GSS1 should be updated to allow for other name types.

Date: Thu, 24 Aug 2006 10:19:28 -0400 (EDT)
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: <[email-masked]>, Sam Hartman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

On Thu, 24 Aug 2006, Alexey Melnikov wrote:

> > Uh, how does that follow?  The original comment was that to meet (5),
> > we needed to require that integ_req_flag be set.  The sole effect of
> > the proposed change is to _remove_ the requirement that that flag be set.
>
> No, the new text requires that this flag is set unconditionally.

You're right; it does.  I completely missed that sentence, somehow.

Date: Thu, 24 Aug 2006 10:52:09 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: [email-masked], Sam Hartman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

Jeffrey Hutzelman wrote:

> On Wednesday, August 23, 2006 03:54:28 PM +0100 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> Alexey Melnikov wrote:
>>
>>>>   5) If the underlying cryptographic technology used by a mechanism
>>>>         supports data integrity, then the mechanism specification MUST
>>>>         integrity protect the transmission of an authorization 
>>>> identity
>>>>         and the negotiation of the security layer.
>>>>
>>>>                     I think the resolution here is to always require
>>>> the integrity flag be set.
>>>
>>> You mean passing integ_req_flag=true to GSS_Init_sec_context?
>>>
>>> This would be fine with me, however this is not the existing practice
>>> (e.g. Cyrus SASL only passes this flag when it also negotiates the
>>> SASL security layer with integrity protection).
>>
>> After the followup conversation with Sam he convinced me that this is 
>> the
>> right thing.
>>
>> OLD text:
>>    If the client will be requesting a security
>>    layer, it MUST also supply to the GSS_Init_sec_context a
>>    mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
>>    integ_req_flag of TRUE.  If the client will be requesting a security
>>    layer providing confidentiality protection, it MUST also supply to
>>    the GSS_Init_sec_context a conf_req_flag of TRUE.
>>
>> NEW text:
>>
>>   When calling the GSS_Init_sec_context the client MUST
>>   pass the integ_req_flag of TRUE. If the client will be requesting a
>> security
>>   layer, it MUST also supply to the GSS_Init_sec_context a
>>   mutual_req_flag of TRUE, and a sequence_req_flag of TRUE.
>>   If the client will be requesting a security
>>   layer providing confidentiality protection, it MUST also supply to the
>>   GSS_Init_sec_context a conf_req_flag of TRUE.
>
> Uh, how does that follow?  The original comment was that to meet (5), 
> we needed to require that integ_req_flag be set.  The sole effect of 
> the proposed change is to _remove_ the requirement that that flag be set.

No, the new text requires that this flag is set unconditionally.

> It has no effect on the requirement to set mutual_req_flag, which was 
> what most of the discussion was about.

Can you please guys make up your mind and tell me which flags must be 
set ;-).

> I think it is worth noting explicitly that merely setting these flags 
> does not guarantee that you will get the desired functionality, or 
> that context establishment will fail if you don't.  For example, if 
> you want a security later with integrity protection, you need to 
> _both_ set inreg_req_flag _and_ verify that integ_avail is set on the 
> resulting context.

If people think that I should add some text about verifying that flags 
were actually set, I can do that. I am not sure after Nico's reply.

Date: Wed, 23 Aug 2006 17:06:09 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Mail-Followup-To: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Sender: [email-masked]

On Wed, Aug 23, 2006 at 05:19:05PM -0400, Jeffrey Hutzelman wrote:
> I think it is worth noting explicitly that merely setting these flags does 
> not guarantee that you will get the desired functionality, or that context 
> establishment will fail if you don't.  For example, if you want a security 
> later with integrity protection, you need to _both_ set inreg_req_flag 
> _and_ verify that integ_avail is set on the resulting context.

You can check for integrity/confidentiality protection support when you
go use per-message tokens.  Since SASL/GS1 immediately does that after
context establishment there's no real need to check these output flags
of GSS_Init_sec_context() or GSS_Accept_sec_context().

Date: Wed, 23 Aug 2006 17:19:05 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, [email-masked]
cc: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Originator-Info: login-token=Mulberry:01eQ4iR+N2l7vFWZrIrIxSthCAWXIAQpvmg1Csr44=; token_authority=[email-masked]
Sender: [email-masked]

On Wednesday, August 23, 2006 03:54:28 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

>
> Alexey Melnikov wrote:
>
>>>   5) If the underlying cryptographic technology used by a mechanism
>>>         supports data integrity, then the mechanism specification MUST
>>>         integrity protect the transmission of an authorization identity
>>>         and the negotiation of the security layer.
>>>
>>>                     I think the resolution here is to always require
>>> the integrity flag be set.
>>
>> You mean passing integ_req_flag=true to GSS_Init_sec_context?
>>
>> This would be fine with me, however this is not the existing practice
>> (e.g. Cyrus SASL only passes this flag when it also negotiates the
>> SASL security layer with integrity protection).
>
> After the followup conversation with Sam he convinced me that this is the
> right thing.
>
> OLD text:
>    If the client will be requesting a security
>    layer, it MUST also supply to the GSS_Init_sec_context a
>    mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
>    integ_req_flag of TRUE.  If the client will be requesting a security
>    layer providing confidentiality protection, it MUST also supply to
>    the GSS_Init_sec_context a conf_req_flag of TRUE.
>
> NEW text:
>
>   When calling the GSS_Init_sec_context the client MUST
>   pass the integ_req_flag of TRUE. If the client will be requesting a
> security
>   layer, it MUST also supply to the GSS_Init_sec_context a
>   mutual_req_flag of TRUE, and a sequence_req_flag of TRUE.
>   If the client will be requesting a security
>   layer providing confidentiality protection, it MUST also supply to the
>   GSS_Init_sec_context a conf_req_flag of TRUE.

Uh, how does that follow?  The original comment was that to meet (5), we 
needed to require that integ_req_flag be set.  The sole effect of the 
proposed change is to _remove_ the requirement that that flag be set.  It 
has no effect on the requirement to set mutual_req_flag, which was what 
most of the discussion was about.

I think it is worth noting explicitly that merely setting these flags does 
not guarantee that you will get the desired functionality, or that context 
establishment will fail if you don't.  For example, if you want a security 
later with integrity protection, you need to _both_ set inreg_req_flag 
_and_ verify that integ_avail is set on the resulting context.

-- Jeff

Date: Wed, 23 Aug 2006 12:44:54 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Aug 23, 2006 at 12:54:36PM -0400, Sam Hartman wrote:
> And so I'd prefer it be non-normative.  The normative requirement
> should be stated in terms of the SASL mechanism: The client MAY use
> another name type if it knows the server will support it.

Sure.

From: Sam Hartman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Date: Wed, 23 Aug 2006 12:54:36 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Aug 23, 2006 at 11:59:24AM -0400, Sam Hartman
    Nicolas> wrote:
    >> A sasl mechanism spec SHOULd NOT make requirements on
    >> application protocol specs.

    Nicolas> The text I proposed had a requirement only for
    Nicolas> applications that would use name types other than the
    Nicolas> default.  I.e., apps need do nothing unless they want to
    Nicolas> use domain-based names.

And so I'd prefer it be non-normative.  The normative requirement
should be stated in terms of the SASL mechanism: The client MAY use
another name type if it knows the server will support it.

Date: Wed, 23 Aug 2006 11:35:01 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Aug 23, 2006 at 11:59:24AM -0400, Sam Hartman wrote:
> A sasl mechanism spec SHOULd NOT make requirements on application
> protocol specs.

The text I proposed had a requirement only for applications that would
use name types other than the default.  I.e., apps need do nothing
unless they want to use domain-based names.

But we could work the requirement out.

Date: Wed, 23 Aug 2006 11:33:41 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Kitten <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Kitten <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Sender: [email-masked]

On Wed, Aug 23, 2006 at 04:41:49PM +0100, Alexey Melnikov wrote:
> Alexey Melnikov wrote:
> 
> >Nicolas Williams wrote:
> >
> >> Applications should specify what alternate name types may be
> >>  used and in what circumstances.
> >
> >Is this a requirement on implementations or protocol specs?
> 
> Also, is this a normative statement or informative?

Normative, like the text in RFC4422, section 4.

Date: Wed, 23 Aug 2006 11:33:14 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Kitten <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Kitten <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Sender: [email-masked]

On Wed, Aug 23, 2006 at 04:13:43PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> 
> >If there's any way to insert text into draft-ietf-sasl-gssapi about this
> >then I would opt for that, though it should not mention domain-based
> >name types specifically.
> >
> BTW, DIGEST-MD5 already allows for domain-based names.

Oh!

I wish the base SASL spec talked about this sort of thing...

> > Applications should specify what alternate name types may be
> >  used and in what circumstances.
> > 
> >
> Is this a requirement on implementations or protocol specs?

Application protocol specs.

Date: Wed, 23 Aug 2006 17:00:30 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: Nicolas Williams <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

Sam Hartman wrote:

>A sasl mechanism spec SHOULd NOT make requirements on application
>protocol specs.
>  
>
This is one of the reasons why I don't like the last sentence proposed 
by Nico. Is "application" means "protocol", the sentence violates the 
SHOULD NOT.

From: Sam Hartman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Date: Wed, 23 Aug 2006 11:59:24 -0400
Sender: [email-masked]

A sasl mechanism spec SHOULd NOT make requirements on application
protocol specs.

Date: Wed, 23 Aug 2006 16:41:49 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

Alexey Melnikov wrote:

> Nicolas Williams wrote:
>
>>  Applications should specify what alternate name types may be
>>   used and in what circumstances.
>
> Is this a requirement on implementations or protocol specs?

Also, is this a normative statement or informative?

From: Sam Hartman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Date: Wed, 23 Aug 2006 11:29:27 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> Nicolas Williams wrote:
    >> If there's any way to insert text into draft-ietf-sasl-gssapi
    >> about this then I would opt for that, though it should not
    >> mention domain-based name types specifically.
    >> 
    Alexey> BTW, DIGEST-MD5 already allows for domain-based names.

    >> Similarly for GS2.  Something like:
    >> 
    >> Clients MAY use name types other than
    >> GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names,
    >> but only when they have a priori knowledge that the servers
    >> support alternate name types.  Otherwise clients MUST use
    >> GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.
    >> 
    Alexey> I am Ok with adding this text.

As AD, I'm OK with adding this text if the SASL WG supports it.

As an individual, I support this text.

Date: Wed, 23 Aug 2006 16:13:43 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

Nicolas Williams wrote:

>If there's any way to insert text into draft-ietf-sasl-gssapi about this
>then I would opt for that, though it should not mention domain-based
>name types specifically.
>
BTW, DIGEST-MD5 already allows for domain-based names.

>Similarly for GS2.  Something like:
>
>   Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to
>   import servers' acceptor names, but only when they have a priori
>   knowledge that the servers support alternate name types.  Otherwise
>   clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
>   names.
>
I am Ok with adding this text.

>  Applications should specify what alternate name types may be
>   used and in what circumstances.
>  
>
Is this a requirement on implementations or protocol specs?

Date: Wed, 23 Aug 2006 15:54:28 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Sam Hartman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

Alexey Melnikov wrote:

>>   5) If the underlying cryptographic technology used by a mechanism
>>         supports data integrity, then the mechanism specification MUST
>>         integrity protect the transmission of an authorization identity
>>         and the negotiation of the security layer.
>>
>>                     I think the resolution here is to always require 
>> the integrity flag be set.
>
> You mean passing integ_req_flag=true to GSS_Init_sec_context?
>
> This would be fine with me, however this is not the existing practice 
> (e.g. Cyrus SASL only passes this flag when it also negotiates the 
> SASL security layer with integrity protection).

After the followup conversation with Sam he convinced me that this is 
the right thing.

OLD text:
   If the client will be requesting a security
   layer, it MUST also supply to the GSS_Init_sec_context a
   mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
   integ_req_flag of TRUE.  If the client will be requesting a security
   layer providing confidentiality protection, it MUST also supply to
   the GSS_Init_sec_context a conf_req_flag of TRUE.

NEW text:

  When calling the GSS_Init_sec_context the client MUST
  pass the integ_req_flag of TRUE. If the client will be requesting a 
security
  layer, it MUST also supply to the GSS_Init_sec_context a
  mutual_req_flag of TRUE, and a sequence_req_flag of TRUE.
  If the client will be requesting a security
  layer providing confidentiality protection, it MUST also supply to the
  GSS_Init_sec_context a conf_req_flag of TRUE.

Date: Wed, 23 Aug 2006 08:10:08 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, Kitten <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Alexey Melnikov <[email-masked]>, Jeffrey Altman <[email-masked]>, Kitten <[email-masked]>, [email-masked], Sam Hartman <[email-masked]>
Sender: [email-masked]

On Wed, Aug 23, 2006 at 11:44:59AM +0100, Alexey Melnikov wrote:
> Jeffrey Altman wrote:
> >                             The question then appears to me to be more
> >general than the question of whether or not SASL-GSS-1 or SASL-GSS-2
> >must be updated.  Instead it appears to be "does SASL support the
> >concept of authentication with domain-based names at all?"
> >
> When integrating SASL into SMTP, IMAP and LDAP servers I always assumed 
> that the answer to this question was "yes".

Well, RFC4422 does require that a service name always be involved
(section 4, item (1)).  But it doesn't actually discuss the structure of
server names -- it doesn't even mention hostnames or domainnames.

What should one take away from this?

That SASL is underspecified on purpose in this area?  If so then one
might conclude that GS1 only provides a default name type for acceptors
and that applications are free to use any other name type provided that
it's some sort of service name type.

Or that SASL is accidentally underspecified and that in practice it only
supports host-based service names?  In which case the base spec and GS1
and/or GS2 need updating.

Nico
-- 

Date: Wed, 23 Aug 2006 11:44:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Altman <[email-masked]>
CC: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

Jeffrey Altman wrote:

>Speaking as an individual and not as Kitten Chair.
>
>Nicolas Williams wrote:
>  
>
>>Sam> It is my reading of gs1 that it normatively requires hostbased names.
>>
>>Sam thinks GS1 excludes use of other name types for acceptors.
>>
>>I think so too, but I'm not sure that GS1/GS2 need updating as much as
>>applications do -- certainly applications that wish to use domain-based
>>names will need updating.
>>
>>I don't read GS1 to prohibit use of other name types but as providing a
>>required name type when a priori knowledge of server support for other
>>name types is not available.  Clients and servers wishing to use name
>>types other than hostbased service clearly have to agree a priori and
>>SASL/GS1 implementations have to make it possible (which they might
>>not); there is no negotiation mechanism..
>>    
>>
>I believe that given the cookbook style language of RFC 2222 that the
>only reasonable interpretation is that only GSS_C_NT_HOSTBASED_SERVICE
>was anticipated being used.   The lack of a MUST or SHOULD implies to
>me that the authors never considered the possibility that there might
>be another name type worth considering or that an alternative usage
>model for SASL might require the use of an alternate name type.
>  
>
I agree with this conclusion (I wasn't working on RFC 2222)

>The situation we are now confronting is a desire to use SASL for a
>usage model that was not previously conceived, authentication involving
>domain-based service names.  The question then appears to me to be more
>general than the question of whether or not SASL-GSS-1 or SASL-GSS-2
>must be updated.  Instead it appears to be "does SASL support the
>concept of authentication with domain-based names at all?"
>
When integrating SASL into SMTP, IMAP and LDAP servers I always assumed 
that the answer to this question was "yes".

>If the answer is 'yes', then the limitations imposed by the cookbook style
>description of how to call GSS_Import_Name from RFC 2222 must be
>clarified to indicate when specific name types should be used.  If the
>answer is that SASL does not support authentication using domain-based
>names, then the SASL working group must decide whether or not it wants
>to support those use cases in their specification.
>
>In either case, I do not believe that answering the SASL question should
>be a road block on the specification of domain-based service names at
>the GSS-API layer.
>  
>

Date: Wed, 23 Aug 2006 12:18:52 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Altman <[email-masked]>
CC: [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

Jeffrey Altman wrote:

>Alexey Melnikov wrote:
>  
>
>>Sam just confirmed that he wanted this paragraph to be removed. If you
>>object, speak up now.
>>    
>>
>Not that I object to it being removed but what discussion lead to that
>text being added?
>  
>
I frankly don't know. I've just checked and this text was in 
draft-ietf-cat-sasl-gssapi-05.txt dated 2001, when John Myers was still 
editing the document.

Date: Tue, 22 Aug 2006 16:11:27 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Sam Hartman <[email-masked]>
cc: Jeffrey Altman <[email-masked]>, Kitten <[email-masked]>, [email-masked], Jeffrey Hutzelman <[email-masked]>
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and	Name Type
Originator-Info: login-token=Mulberry:01RM5MMa42waWQGcSyd0x8oNtAg1zLAsWxQ3qWek4=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, August 22, 2006 03:36:48 PM -0400 Sam Hartman 
<[email-masked]> wrote:

>>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
>
>     Jeffrey> On Tuesday, August 22, 2006 01:48:36 PM -0400 Jeffrey
>     Jeffrey> Altman
>     Jeffrey> <[email-masked]> wrote:
>
>     >> In either case, I do not believe that answering the SASL
>     >> question should be a road block on the specification of
>     >> domain-based service names at the GSS-API layer.
>
>     Jeffrey> Nor do I.  I see immediate uses for domain-based service
>     Jeffrey> names in a variety of non-SASL applications, including
>     Jeffrey> SSH, AFS, and NFSv4, just to name a few.  Yes, it may be
>     Jeffrey> necessary in some cases to modify the application
>     Jeffrey> protocol specifications to allow the use of domain-based
>     Jeffrey> names.  I don't consider that to be a significant
>     Jeffrey> problem.
>
> In order to take the document to the IESG I need to be convinced that
> it is done.  It would be much easier for me to do that if I saw how to
> adapt existing applications.

Personally, I'd love to be able to assume that if you can get as far as the 
first call to init_sec_context, then all is well; that's the technique that 
applications already use to determine whether to offer a GSS-API-based 
mechanism at all.  But, as Nico pointed out, that may not work for every 
mechanism - there will certainly be mechanims for which clients can get 
credentials for _any_ service name.

So, there needs to be an application-specific negotiation.  For SSH key 
exchange, I'd expect that to take the form of a new family of mechanism 
names.  For SSH user auth, I'd expect clients to try with a domain-based 
service name, and then fall back to trying the same mechanism with a 
host-based service name.  For _new_ applications, one might simply specify 
the use of domain-based service names to begin with.

-- Jeff

Date: Tue, 22 Aug 2006 14:45:04 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Jeffrey Altman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Sam Hartman <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Jeffrey Altman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 22, 2006 at 03:36:48PM -0400, Sam Hartman wrote:
> In order to take the document to the IESG I need to be convinced that
> it is done.  It would be much easier for me to do that if I saw how to
> adapt existing applications.

See text I just posted.  Please add suggestions.

I am willing to submit an Internet-Draft describing NFSv4 domain root
server discovery if it would help.  It would essentially contain the
text I just posted, using 'nfs' as the GSS-API service name, and
'_nfs._tcp.<domainname>.' as the SRV RR name.  No negotiation would be
provided; instead use of domain-based acceptor names for root servers
would be REQUIRED, with the ability to optionally configure use of
host-based names for specific domains, or all domains.  Such a document
would not say much more, if anything, about NFSv4 global namespace
construction.  I am not sure how quickly such a document could progress,
or how quickly it could become an NFSv4 WG item, if at all.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Date: Tue, 22 Aug 2006 15:36:48 -0400
Sender: [email-masked]

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

    Jeffrey> On Tuesday, August 22, 2006 01:48:36 PM -0400 Jeffrey
    Jeffrey> Altman
    Jeffrey> <[email-masked]> wrote:

    >> In either case, I do not believe that answering the SASL
    >> question should be a road block on the specification of
    >> domain-based service names at the GSS-API layer.

    Jeffrey> Nor do I.  I see immediate uses for domain-based service
    Jeffrey> names in a variety of non-SASL applications, including
    Jeffrey> SSH, AFS, and NFSv4, just to name a few.  Yes, it may be
    Jeffrey> necessary in some cases to modify the application
    Jeffrey> protocol specifications to allow the use of domain-based
    Jeffrey> names.  I don't consider that to be a significant
    Jeffrey> problem.

In order to take the document to the IESG I need to be convinced that
it is done.  It would be much easier for me to do that if I saw how to
adapt existing applications.

Date: Tue, 22 Aug 2006 15:25:00 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Jeffrey Altman <[email-masked]>, Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Originator-Info: login-token=Mulberry:01ALD1RmoYarpM+23HMy4ltZciLHGH5G5tJSOrNjA=; token_authority=[email-masked]
Sender: [email-masked]

On Tuesday, August 22, 2006 01:48:36 PM -0400 Jeffrey Altman 
<[email-masked]> wrote:

> In either case, I do not believe that answering the SASL question should
> be a road block on the specification of domain-based service names at
> the GSS-API layer.

Nor do I.  I see immediate uses for domain-based service names in a variety 
of non-SASL applications, including SSH, AFS, and NFSv4, just to name a 
few.  Yes, it may be necessary in some cases to modify the application 
protocol specifications to allow the use of domain-based names.  I don't 
consider that to be a significant problem.

-- Jeff

Date: Tue, 22 Aug 2006 14:12:31 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 22, 2006 at 02:47:20PM -0400, Sam Hartman wrote:
> Note that for things like krb5,, the existence of the domain based
> principal may serve as a hint that domain based names are OK.

But this is very specific to Kerberos V.  I would not want to rely on
this for negotiation, though I'd be happy with a MAY about it.

From: Sam Hartman <[email-masked]>
To: Kitten <[email-masked]>
Date: Tue, 22 Aug 2006 14:47:20 -0400
Cc: [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

Note that for things like krb5,, the existence of the domain based
principal may serve as a hint that domain based names are OK.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

From: Sam Hartman <[email-masked]>
To: Kitten <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Date: Tue, 22 Aug 2006 14:47:20 -0400
Sender: [email-masked]

Note that for things like krb5,, the existence of the domain based
principal may serve as a hint that domain based names are OK.

Date: Tue, 22 Aug 2006 13:48:36 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010702060702050102070009
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Speaking as an individual and not as Kitten Chair.

Nicolas Williams wrote:
> Sam> It is my reading of gs1 that it normatively requires hostbased names.
> 
> Sam thinks GS1 excludes use of other name types for acceptors.
>
> I think so too, but I'm not sure that GS1/GS2 need updating as much as
> applications do -- certainly applications that wish to use domain-based
> names will need updating.
> 
> I don't read GS1 to prohibit use of other name types but as providing a
> required name type when a priori knowledge of server support for other
> name types is not available.  Clients and servers wishing to use name
> types other than hostbased service clearly have to agree a priori and
> SASL/GS1 implementations have to make it possible (which they might
> not); there is no negotiation mechanism..

I believe that given the cookbook style language of RFC 2222 that the
only reasonable interpretation is that only GSS_C_NT_HOSTBASED_SERVICE
was anticipated being used.   The lack of a MUST or SHOULD implies to
me that the authors never considered the possibility that there might
be another name type worth considering or that an alternative usage
model for SASL might require the use of an alternate name type.

The situation we are now confronting is a desire to use SASL for a
usage model that was not previously conceived, authentication involving
domain-based service names.  The question then appears to me to be more
general than the question of whether or not SASL-GSS-1 or SASL-GSS-2
must be updated.  Instead it appears to be "does SASL support the
concept of authentication with domain-based names at all?"  If the
answer is 'yes', then the limitations imposed by the cookbook style
description of how to call GSS_Import_Name from RFC 2222 must be
clarified to indicate when specific name types should be used.  If the
answer is that SASL does not support authentication using domain-based
names, then the SASL working group must decide whether or not it wants
to support those use cases in their specification.

In either case, I do not believe that answering the SASL question should
be a road block on the specification of domain-based service names at
the GSS-API layer.

Jeffrey Altman

--------------ms010702060702050102070009
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010702060702050102070009--

Date: Tue, 22 Aug 2006 12:31:00 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>, Kitten <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 22, 2006 at 12:24:19PM -0500, Nicolas Williams wrote:
>                               Clients and servers wishing to use name
> types other than hostbased service clearly have to agree a priori and
> SASL/GS1 implementations have to make it possible (which they might
> not); there is no negotiation mechanism..

Well, there will have to be negotiation mechanisms, but these will have
to be application-specific.  For NFSv4 the mere existence of the
relevant SRV RRs should indicate that the given NFSv4 servers support
domain-based names.  For applications where existing clients already SRV
RRs the apps may need to specify a new front label for the SRV RR lookup
such that presence of the RRs for the new names indicates support for
domain-based names.

Yes, I think the domain-based name type I-D should have additional text
about this.  I will post a proposal later today.

Nico
-- 

Date: Tue, 22 Aug 2006 12:24:19 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>, Kitten <[email-masked]>
Cc: [email-masked]
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Sam Hartman <[email-masked]>, Kitten <[email-masked]>, [email-masked]
Sender: [email-masked]

Sam> It is my reading of gs1 that it normatively requires hostbased names.

Sam thinks GS1 excludes use of other name types for acceptors.

I think so too, but I'm not sure that GS1/GS2 need updating as much as
applications do -- certainly applications that wish to use domain-based
names will need updating.

I don't read GS1 to prohibit use of other name types but as providing a
required name type when a priori knowledge of server support for other
name types is not available.  Clients and servers wishing to use name
types other than hostbased service clearly have to agree a priori and
SASL/GS1 implementations have to make it possible (which they might
not); there is no negotiation mechanism..

Applications will require updates to use domain-based names.

GS1 can be said to be a GSS-API application, thus it would need an
update, but SASL/GS1 applications will need updates also, which brings
us to: why bother updating GS1 for this then?

I think the answer would be "so that SASL/GS1 implementors could know to
design their APIs accordingly."

Again, the applications we have in mind: LDAP server discovery through
DNS SRV RRs, and NFSv4 root server discovery through DNS SRV RRs.

If there's any way to insert text into draft-ietf-sasl-gssapi about this
then I would opt for that, though it should not mention domain-based
name types specifically.  Similarly for GS2.  Something like:

   Clients MAY use name types other than GSS_C_NT_HOSTBASED_SERVICE to
   import servers' acceptor names, but only when they have a priori
   knowledge that the servers support alternate name types.  Otherwise
   clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor
   names.  Applications should specify what alternate name types may be
   used and in what circumstances.

> Should we hold this discussion on the SASL list?

I'll assume yes.  Cross-posting.

Nico
-- 

Date: Tue, 22 Aug 2006 10:52:06 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Kitten <[email-masked]>
Subject: Re: Working Group Last Call: GSS-API Domain-Based Service Names and Name Type
Mail-Followup-To: Sam Hartman <[email-masked]>, Kitten <[email-masked]>
Sender: [email-masked]

On Mon, Aug 21, 2006 at 07:24:07PM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> You seem to be assuming that the domain in a domain based names has
> anything to do with the realm.  I assume it had to do with the string
> used for srv record lookups.  Why would you have two different ldap
> schemas in the same srv record rotation?

Right, thank you -- you've just made my instance naming concern go away.

Perhaps I should add some text specifically describing application use
of domain-based names in conjunction with DNS SRV RR lookups.

>     Nicolas> The SASL/GS1 mechanism (RFC2222, draft-ietf-sasl-gssapi)
>     Nicolas> mention GSS-API name types, or one name type anyways,
>     Nicolas> GSS_C_NT_HOSTBASED_SERVICE, but don't define any strict
>     Nicolas> API, so I'm not sure that SASL/GS1 constrains us here, or
>     Nicolas> requires updating
> It is my reading of gs1 that it normatively requires hostbased names.

That it does, but to the exclusion of all others?  That I'm not sure of;
RFC2222 does say "MUST use GSS_C_NT_HOSTBASED_SERVICE for acceptor
names."  Perhaps that was an oversight and we should read it as
normatively requiring use of hostbased service principal names for
acceptors.  If we do this then, then would we be able to update GS1?

Should we hold this discussion on the SASL list?

Nico
-- 

Date: Tue, 22 Aug 2006 10:16:38 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070208090700090304060301
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:

> Sam just confirmed that he wanted this paragraph to be removed. If you
> object, speak up now.

Not that I object to it being removed but what discussion lead to that
text being added?

Jeffrey Altman

--------------ms070208090700090304060301
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070208090700090304060301--

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Please compute GS2 mechanism name for krb5
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 22 Aug 2006 15:52:08 +0200
Sender: [email-masked]

Hi.

For my implementation of GS2, I derived the mechanism name for the
krb5 mechanism manually; i.e., gs2-base32(ten(sha1(der(krb5-oid)))).

To avoid poor interop experiences later on, could someone please
independently compute this value as well?

I believe we should add the computed gs2 mechanism name for krb5 as an
example in the specification; I suspect it will be hard-coded in many
implementations.

Thanks,
Simon

Date: Tue, 22 Aug 2006 10:52:44 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: Sam Hartman <[email-masked]>
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

Alexey Melnikov wrote:

>> I believe the following text may be generally false for gssapi
>> mechanisms and is certainly false for RFC 4121.  I think it is false
>> for 1964 if a client asserts a subkey.
>>
>>
>>   The integrity protection provided by the GSSAPI security layer is
>>   useless to the client unless the client also requests mutual
>>   authentication.  Therefore, a client wishing to benefit from the
>>   integrity protection of a security layer MUST pass to the
>>   GSS_Init_sec_context call a mutual_req_flag of TRUE.
>>
>> In particular I think SASL's use of gssapi will get it mutual auth
>> regardless of whether it requests mutual auth.
>
> Do you recommend to remove the quoted paragraph?

Sam just confirmed that he wanted this paragraph to be removed. If you 
object, speak up now.

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository
Date: Fri, 18 Aug 2006 10:23:57 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Nicolas Williams <[email-masked]> writes:

    >> Folks, the replacement for draft-ietf-nfsv4-channel-bindings,
    >> draft-williams-on-channel-binding-00.txt, is now in the I-D
    >> repository.
    >> 
    >> It has also been significantly expanded.  Please review.  I'd
    >> like to ask the security ADs for an IETF Last Call on this I-D
    >> soon.

    Simon> Looks good in general.  A general design question:

    Simon> What about SASL/GS2 over TLS over SSH over IPSEC?  What is
    Simon> the channel bindings for that, is it only the TLS binding?
    Simon> Consider if the application regards the TLS layer as weak
    Simon> (export ciphers) but the SSH layer as strong, would it be
    Simon> permitted to use the SSH channel binding?  This sounds to
    Simon> me like it may require negotiation in GS2.

That's the application's problem to decide.

I definitely do not think we want every mechanism that supports
binding to a channel to need negotiation for this.

Date: Wed, 16 Aug 2006 12:35:44 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Updated milestones
Sender: [email-masked]

Please note the WG milestones have been updated.  These are
the remaining outstanding milestones: 

Sep 2006    Submit GS2 to IESG for consideration as a Proposed Standard 
Sep 2006    Submit CRAM-MD5 to IESG for consideration as a Proposed Standard 
Oct 2006    Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard 
Oct 2006    Provide implementation report plan (with milestones) 
Nov 2006    Revise charter or conclude 

The delivery dates are basically as discussed at IETF#66 with an
extra month given to complete our DIGEST-MD5 work.

You can expect WGLCs to be issued on the remaining documents
soon (allowing editors to revise once more to resolve known
issues).

-- Kurt

Date: Wed, 16 Aug 2006 13:19:18 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
cc: Jeffrey Hutzelman <[email-masked]>
Subject: Re: CRAM-MD5 applicability statement
Originator-Info: login-token=Mulberry:01DADOuHZoQyxYS0Y5P37+J6NyBeOTNEd5dfwdQoA=; token_authority=[email-masked]
Sender: [email-masked]

On Monday, August 14, 2006 08:36:10 PM -0700 "Kurt D. Zeilenga" 
<[email-masked]> wrote:

> I am also concerned by the inclusion of the last paragraph of
> security consideration section.  As most mechanisms, including
> DIGEST-MD5, that provide data security services do so
> as an elective service, the example seems flawed.  But more
> importantly, I would think that data integrity protective
> services would likely be needed in deployments of an "amateur
> radio service", and CRAM-MD5 offers none.  Data integrity
> protective services do not "obscure communications".

I agree; the example is flawed.  Regulations governing the amateur radio 
service prohibit the use of encryption, not the use of protocols which 
provide optional support for it.  Further, were I using a SASL application 
over a network connection involving an IP-over-AX.25 link (or something 
similar), I would certainly want to use some form of data integrity. 
Besides being easy to sniff, radio links are also fairly easy to jam and 
override, depending on the attacker's location and how much power he is 
willing and/or able to use.  That is, such links are especially vulnerable 
to connection hijacking.

I would suggest removing the example, if not the entire paragraph.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: CRAM-MD5 applicability statement
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 16 Aug 2006 17:30:10 +0200
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> At 05:25 AM 8/16/2006, Simon Josefsson wrote:
>
>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>
>>> At IETF#66, I agreed to suggest text for a CRAM-MD5 applicability
>>> statement suitable for inclusion in draft-ietf-sasl-crammd5-07.
>>>
>>>   The CRAM-MD5 mechanism is intended to have limited use on the
>>>   Internet.
>>
>>CRAM-MD5 is widely used on the Internet already, perhaps rephrasing
>>that as
>>
>>  The use of the CRAM-MD5 mechanism is intended to be phased out.
>>
>>would better reflect the current deployment, and what we attempt to
>>aim for.
>
> "Limited use" characterizes the applicability not the deployment size.

Ok.

>>>   Designers considering profiling use of this mechanism in their
>>>   application-level protocols should consider alternative mechanisms
>>>   intended for common use, such as DIGEST-MD5.
>>
>>Here I have to disagree.  DIGEST-MD5 is not a better choice.
>
> DIGEST-MD5 is used here as an example of a mechanism which is
> intended for common use.  I have no objection to replacing
> DIGEST-MD5 with another mechanism which is intended for
> common use, or simply removing the phrase "such as DIGEST-MD5'.

Either seems fine to me.

Thanks,
Simon

Date: Wed, 16 Aug 2006 08:12:45 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: CRAM-MD5 applicability statement
Cc: [email-masked]
Sender: [email-masked]

At 05:25 AM 8/16/2006, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> At IETF#66, I agreed to suggest text for a CRAM-MD5 applicability
>> statement suitable for inclusion in draft-ietf-sasl-crammd5-07.
>>
>>   The CRAM-MD5 mechanism is intended to have limited use on the
>>   Internet.
>
>CRAM-MD5 is widely used on the Internet already, perhaps rephrasing
>that as
>
>  The use of the CRAM-MD5 mechanism is intended to be phased out.
>
>would better reflect the current deployment, and what we attempt to
>aim for.

"Limited use" characterizes the applicability not the deployment size.

>>   Designers considering profiling use of this mechanism in their
>>   application-level protocols should consider alternative mechanisms
>>   intended for common use, such as DIGEST-MD5.
>
>Here I have to disagree.  DIGEST-MD5 is not a better choice.

DIGEST-MD5 is used here as an example of a mechanism which is
intended for common use.  I have no objection to replacing
DIGEST-MD5 with another mechanism which is intended for
common use, or simply removing the phrase "such as DIGEST-MD5'.

Kurt

From: Simon Josefsson <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: CRAM-MD5 applicability statement
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 16 Aug 2006 14:25:13 +0200
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> At IETF#66, I agreed to suggest text for a CRAM-MD5 applicability
> statement suitable for inclusion in draft-ietf-sasl-crammd5-07.
>
>   The CRAM-MD5 mechanism is intended to have limited use on the
>   Internet.

CRAM-MD5 is widely used on the Internet already, perhaps rephrasing
that as

  The use of the CRAM-MD5 mechanism is intended to be phased out.

would better reflect the current deployment, and what we attempt to
aim for.

>   The mechanism offers inadequate protection against common attacks
>   against application-level protocols (see the Security
>   Considerations section) and is prone to interoperability problems
>   (see Interoperability Considerations section).

Right.

>   Designers considering profiling use of this mechanism in their
>   application-level protocols should consider alternative mechanisms
>   intended for common use, such as DIGEST-MD5.

Here I have to disagree.  DIGEST-MD5 is not a better choice.  I
believe both PLAIN and CRAM-MD5 (over TLS) offers both better security
properties and better interoperability properties compared to
DIGEST-MD5 (RFC 2831).

To recall, RFC 2831 offers 3des, des and rc4.  Of them, des and 3des
are known to not interoperate at all (they are removed in RFC
2831bis), and rc4 is known to be weak, so the privacy layers of
DIGEST-MD5 are worse than those of TLS.  Further, RFC 2831 has the
same problem with use of normalization (SASLPrep) as CRAM-MD5 does;
although PLAIN doesn't have this problem.  None of them support
channel bindings.

PLAIN (over TLS) thus appears to provide better security and
normalization properties, compared to DIGEST-MD5 and CRAM-MD5.

If RFC 2831bis were close to being approved, and DIGEST-MD5 in the
statement above referred to it, my concern would be smaller, but to
recommend people to move from CRAM-MD5 to RFC 2831 seems wrong to me.
I read the above to imply that.

Having the statement refer to RFC 2831bis instead, which still has
outstanding issues, seems wrong to me as well.  That document could
very well change again, or be published as INFORMATIONAL or HISTORIC
as well.

Since PLAIN has been approved by the IESG, changing DIGEST-MD5 to
PLAIN would be one solution.  Dropping the last sentence may be
better, since PLAIN doesn't offer a channel binding, and we really
doesn't have any good password-based SASL mechanism.

/Simon

Date: Tue, 15 Aug 2006 17:45:54 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository
Mail-Followup-To: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Aug 15, 2006 at 02:46:15PM -0500, Nicolas Williams wrote:
> What mailing list would be approapriate to host reviews of this draft?
> 
> NFSv4's does not seem apropriate, but then, neither do the other two
> (SASL, KITTEN).  Perhaps SASL, because we've been discussing channel
> binding issues in the context of SASL/GS2 there.

Sam suggests the SAAG list (duh!).

Reply-to set.

Nico
-- 

Date: Tue, 15 Aug 2006 14:46:15 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [nfsv4] draft-williams-on-channel-binding-00.txt is in the I-D repository
Reply-To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

What mailing list would be approapriate to host reviews of this draft?

NFSv4's does not seem apropriate, but then, neither do the other two
(SASL, KITTEN).  Perhaps SASL, because we've been discussing channel
binding issues in the context of SASL/GS2 there.

Nico
-- 

Date: Tue, 15 Aug 2006 14:28:00 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-williams-on-channel-binding-00.txt is in the	I-D	repository
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Aug 15, 2006 at 08:50:41PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> 
> [...]
> I'm using IMAP with SASL over TLS over port-forwarded SSH to read my
> mail every day, and I imagine this (TLS over VPN) isn't too uncommon.
> Adding IPSEC doesn't seem entirely far fetched, especially if
> usability of IPSEC improves.

VPNs aren't "channels" as far as this spec goes.  They're not end2end
(nor hop-by-hop proxy systems, like HTTP).

> > It seems to me that the right thing would be to bind each channel to the
> > one below, so here the SSHv2 channel would be bound to the IPsec
> > channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the
> > TLS channel, and the only channel that would provide cryptographic
> > session protection would be IPsec.
> 
> Sounds OK to me, but I'm not sure it is the only solution.

I think it's the simplest, if indeed this is what you want and if the
SSHv2 session ID can be obtained by both, the IMAP client and the IMAP
server.  As it is you called it a VPN, which, IMO, rules channel binding
out.

> > And with port-forwarding the channel binding to SSHv2 would require that
> > the TLS peers know about the SSHv2 channel and its session ID, at which
> > point one might dispense with TLS altogether and just use SASL/GS2 with
> > channel binding to SSHv2
> 
> Implementing all this seems complex.  Applications or TLS libraries
> typically have no idea that it is running over SSH port-forwarding.

You'd have to make them aware of what's below.  That's one of the
problems with channel binding to IPsec: the lack of a) IPsec channels,
b) IPsec APIs relevant to IPsec channels.

Yes, channel binding requires new interfaces.  You've discovered this
already in the context of TLS.  But it's a generic requirement: any
channel you might want to bind to has to export its channel bindings,
a minimum of information about what security services it provides, and
maybe even more (see security considerations text about cryptographic
profiles).

> > Also, we'd have to explain how to bind TLS and SSHv2 to other channels...
> 
> ...that seem to require some additional specification work.

But noone is asking for that.  I'll wait for you to digest my comment
about VPNs before counting you as wanting TLS/SSHv2 channel binding.

> >> Some specific comments:
> [...]
> Thinking more about this, I'd be happy if the "easily" is dropped from
> your paragraph.  If it is only "difficult" (in contrast to
> "computationally infeasible") to force two channel bindings to be the
> same, I don't think it is good enough.

Sure.

> [...]
> 
> SSH host keys are usually verified out of band, if I'm not mistaken.

Irrelevant for either of the two types of channel bindings described in
the draft: a) because an MITM can't obtain the private key to a server's
host public key and this public key is worked into the session ID
computation, b) because SSHv2 uses ephemeral-ephemeral Diffie-Hellman
for key exchange and the result of the initial key exchange too is
worked into the session ID computation.

So whether you're using an SSHv2 host public key or an SSHv2 session ID
as a channel binding an MITM cannot make this binding agree for both,
its connection to the client and its connection to the server.

> I think authentication of (the source to) keying material in TLS-PSK
> and TLS-OpenPGP also happens out of band.

Irrelevant, for similar reasons.

> Anyway, the only real concern I have is the
> GS2-over-TLS-over-SSH-over-IPSEC situation, otherwise I think the
> document is ready.  I'm not sure it should move forward until at least
> the TLS channel bindings document is close to done too, though.

Maybe, but I want additional reviews, not least Sam's.  Thanks!

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D	repository
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 15 Aug 2006 20:50:41 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> What about SASL/GS2 over TLS over SSH over IPSEC?  What is the channel
>> bindings for that, is it only the TLS binding?  Consider if the
>> application regards the TLS layer as weak (export ciphers) but the SSH
>> layer as strong, would it be permitted to use the SSH channel binding?
>> This sounds to me like it may require negotiation in GS2.
>
> How might you end up with such a complex stack?  Are you thinking of
> port-forwarding LDAP/IMAP over SSHv2?

I'm using IMAP with SASL over TLS over port-forwarded SSH to read my
mail every day, and I imagine this (TLS over VPN) isn't too uncommon.
Adding IPSEC doesn't seem entirely far fetched, especially if
usability of IPSEC improves.

> It seems to me that the right thing would be to bind each channel to the
> one below, so here the SSHv2 channel would be bound to the IPsec
> channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the
> TLS channel, and the only channel that would provide cryptographic
> session protection would be IPsec.

Sounds OK to me, but I'm not sure it is the only solution.

> This seems fairly unrealistic though -- aside from port-forwarding I've
> a hard time imagining how one would end up with such a complex stack.

I'm thinking of port-forwarding.

> And with port-forwarding the channel binding to SSHv2 would require that
> the TLS peers know about the SSHv2 channel and its session ID, at which
> point one might dispense with TLS altogether and just use SASL/GS2 with
> channel binding to SSHv2

Implementing all this seems complex.  Applications or TLS libraries
typically have no idea that it is running over SSH port-forwarding.
And SSH implementation usually have no idea that is running over
IPSEC.  And...

> Also, we'd have to explain how to bind TLS and SSHv2 to other channels...

...that seem to require some additional specification work.

>> Some specific comments:
>> 
>> Section 2.1:
>> 
>>   o  The channel bindings for a given type of secure channel MUST be
>>       constructed in such a way that an MITM could not easily force the
>>       channel bindings of a given channel to match those of another.
>> 
>> I'd change this to:
>> 
>>   o  The channel bindings for a given type of secure channel MUST be
>>       constructed in such a way that an MITM cannot influence the
>>       channel bindings.
>
> Why?  The crucial requirement is the one I give.
>
>> This drops "easily", and makes the requirement a bit stronger; the
>> MITM should not have any influence over the channel bindings.
>
> But the MITM does have some influence over the channel bindings, just
> not necessarily control over them :)
>
> IOW, I think you need to pick a better word than 'influence', and,
> anyways, I think the stated requirement is sufficiently strong.

Thinking more about this, I'd be happy if the "easily" is dropped from
your paragraph.  If it is only "difficult" (in contrast to
"computationally infeasible") to force two channel bindings to be the
same, I don't think it is good enough.

>> This:
>> 
>>    o  Unique channel bindings MUST bind not only the key exchange for
>>       the secure channel, but also any negotiations and authentication
>>       that may have taken place to establish the channel.
>> 
>> Sometimes negotiations/authentications are done by other protocols, or
>> even out-of-band over the phone, and the intention was not to cover
>> those things, right?  I'm not sure how to phrase it better, though.
>
> Well, I don't want to be specific about in-band vs. out of band
> negotiation.  Consider the IPsec case, where we bind to the "identities"
> (valid cert names, public keys, ...) bound into the KE[*] exchanges that
> spawn the SAs that protect a given connection's traffic.  Here there's
> not a single negotiation/key exchange/authentication step, but
> potentially many, nor do we bind to "in-band" ESP/AH things but to
> KE-specific ones.
>
> As for "out-of-band over the phone" -- sorry, but manual protocols are
> out of scope.  The intention is to cover: SSHv2, TLS, IPsec and
> protocols that have similar design patterns.  However, I'd like the text
> to be generic, and I think this text mostly captures the intended
> requirement generically.

SSH host keys are usually verified out of band, if I'm not mistaken.

I think authentication of (the source to) keying material in TLS-PSK
and TLS-OpenPGP also happens out of band.

I understand that the intention isn't to cover those kind of
negotiations/authentications, but I'm not sure the text captures this.

I don't know what the exact property we are looking for here (in-band
vs out-of-band doesn't seem to be it).

> Perhaps we should replace "exchange" with "exchange(s)" to reflect the
> potential, in the IPsec channel construction case, for having more than
> one exchange.  And it should be clear that the binding can be quite
> indirect, as it would be in the IPsec case.
>
> So:
>
>    o  Unique channel bindings MUST bind not only the key exchange(s) for
>       the secure channel, but also any negotiations and authentication
>       that may have taken place to establish the channel.
>
>       The binding MAY be indirect, as in the case of end-point channel
>       bindings, where the channel bindings consist of end-point "names"
>       that are strongly bound, through authentication, to the key
>       exchange and negotiation.

Ok.

Anyway, the only real concern I have is the
GS2-over-TLS-over-SSH-over-IPSEC situation, otherwise I think the
document is ready.  I'm not sure it should move forward until at least
the TLS channel bindings document is close to done too, though.

/Simon

Date: Tue, 15 Aug 2006 12:36:23 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D	repository
Mail-Followup-To: Simon Josefsson <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Aug 15, 2006 at 06:47:35PM +0200, Simon Josefsson wrote:
> Looks good in general.  A general design question:

Thanks for your comments!

> What about SASL/GS2 over TLS over SSH over IPSEC?  What is the channel
> bindings for that, is it only the TLS binding?  Consider if the
> application regards the TLS layer as weak (export ciphers) but the SSH
> layer as strong, would it be permitted to use the SSH channel binding?
> This sounds to me like it may require negotiation in GS2.

How might you end up with such a complex stack?  Are you thinking of
port-forwarding LDAP/IMAP over SSHv2?

It seems to me that the right thing would be to bind each channel to the
one below, so here the SSHv2 channel would be bound to the IPsec
channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the
TLS channel, and the only channel that would provide cryptographic
session protection would be IPsec.

This seems fairly unrealistic though -- aside from port-forwarding I've
a hard time imagining how one would end up with such a complex stack.
And with port-forwarding the channel binding to SSHv2 would require that
the TLS peers know about the SSHv2 channel and its session ID, at which
point one might dispense with TLS altogether and just use SASL/GS2 with
channel binding to SSHv2 (even the SSHv2 channel is not end2end, unless
you want end2end protection, in which case there'd be no need for
channel binding of TLS to the SSHv2 channel).

Also, we'd have to explain how to bind TLS and SSHv2 to other channels...

Consider the examples given so far:

 - NFSv4, iSCSI, other similar protocols, with channel binding to IPsec
 - Extended HTTP authentication with channel binding to TLS

and the reasons for these examples:

 - app-layer authentication fits better (NFSv4, HTTP)
 - app-layer has to be in cleartext relative to a lower layer (NFSv4,
   iSCSI [iSER])
 - better HW support for cryptographic protocols lower in the stack
   (all)

SSHv2 applications don't have the problems that NFSv4 has: they neither
multiplex multiple users on one connection, lack applicable user
authentication methods, or have the RDDP problem.  So channel binding
SSHv2 to a lower layer session makes sense only for HW crypto
acceleration -- though that alone does make a lot of sense.  

> Some specific comments:
> 
> Section 2.1:
> 
>   o  The channel bindings for a given type of secure channel MUST be
>       constructed in such a way that an MITM could not easily force the
>       channel bindings of a given channel to match those of another.
> 
> I'd change this to:
> 
>   o  The channel bindings for a given type of secure channel MUST be
>       constructed in such a way that an MITM cannot influence the
>       channel bindings.

Why?  The crucial requirement is the one I give.

> This drops "easily", and makes the requirement a bit stronger; the
> MITM should not have any influence over the channel bindings.

But the MITM does have some influence over the channel bindings, just
not necessarily control over them :)

IOW, I think you need to pick a better word than 'influence', and,
anyways, I think the stated requirement is sufficiently strong.

> This:
> 
>    o  Unique channel bindings MUST bind not only the key exchange for
>       the secure channel, but also any negotiations and authentication
>       that may have taken place to establish the channel.
> 
> Sometimes negotiations/authentications are done by other protocols, or
> even out-of-band over the phone, and the intention was not to cover
> those things, right?  I'm not sure how to phrase it better, though.

Well, I don't want to be specific about in-band vs. out of band
negotiation.  Consider the IPsec case, where we bind to the "identities"
(valid cert names, public keys, ...) bound into the KE[*] exchanges that
spawn the SAs that protect a given connection's traffic.  Here there's
not a single negotiation/key exchange/authentication step, but
potentially many, nor do we bind to "in-band" ESP/AH things but to
KE-specific ones.

As for "out-of-band over the phone" -- sorry, but manual protocols are
out of scope.  The intention is to cover: SSHv2, TLS, IPsec and
protocols that have similar design patterns.  However, I'd like the text
to be generic, and I think this text mostly captures the intended
requirement generically.

Perhaps we should replace "exchange" with "exchange(s)" to reflect the
potential, in the IPsec channel construction case, for having more than
one exchange.  And it should be clear that the binding can be quite
indirect, as it would be in the IPsec case.

So:

   o  Unique channel bindings MUST bind not only the key exchange(s) for
      the secure channel, but also any negotiations and authentication
      that may have taken place to establish the channel.

      The binding MAY be indirect, as in the case of end-point channel
      bindings, where the channel bindings consist of end-point "names"
      that are strongly bound, through authentication, to the key
      exchange and negotiation.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: draft minutes SASL WG @ IETF66
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 15 Aug 2006 18:50:13 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Thu, Aug 10, 2006 at 11:56:49PM -0400, Tom Yu wrote:
>> GS2:
>> ====
>> 
>> Simon Josefsson leads discussion via Jabber
>> 
>> Main open issue is channel bindings.  Sam and others feel that channel
>> bindings to TLS should be specified in a general way and not in this
>> document and not in this WG.  Nico kind of has an individual
>> submission relating to this.  TLS PRF is probably the way to handle
>> channel bindings.  Lengthy discussion about whether TLS
>> implementations provide access to PRF, also whether to use some hash
>> of TLS finished messages.
>
> draft-williams-on-channel-binding-00.txt was submitted today.
>
> It replaces draft-ietf-nfsv4-channel-bindings-03.txt.
>
> Neither was in the I-D repository at the time of IETF66 however :)

I believe the above referred to draft-ietf-nfsv4-channel-bindings-02,
which included a definition of TLS channel bindings.

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 15 Aug 2006 18:47:35 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> Folks, the replacement for draft-ietf-nfsv4-channel-bindings,
> draft-williams-on-channel-binding-00.txt, is now in the I-D repository.
>
> It has also been significantly expanded.  Please review.  I'd like to
> ask the security ADs for an IETF Last Call on this I-D soon.

Looks good in general.  A general design question:

What about SASL/GS2 over TLS over SSH over IPSEC?  What is the channel
bindings for that, is it only the TLS binding?  Consider if the
application regards the TLS layer as weak (export ciphers) but the SSH
layer as strong, would it be permitted to use the SSH channel binding?
This sounds to me like it may require negotiation in GS2.

Some specific comments:

Section 2.1:

  o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM could not easily force the
      channel bindings of a given channel to match those of another.

I'd change this to:

  o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM cannot influence the
      channel bindings.

This drops "easily", and makes the requirement a bit stronger; the
MITM should not have any influence over the channel bindings.

This:

   o  Unique channel bindings MUST bind not only the key exchange for
      the secure channel, but also any negotiations and authentication
      that may have taken place to establish the channel.

Sometimes negotiations/authentications are done by other protocols, or
even out-of-band over the phone, and the intention was not to cover
those things, right?  I'm not sure how to phrase it better, though.

/Simon

Date: Tue, 15 Aug 2006 10:08:54 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: draft-williams-on-channel-binding-00.txt is in the I-D repository
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Folks, the replacement for draft-ietf-nfsv4-channel-bindings,
draft-williams-on-channel-binding-00.txt, is now in the I-D repository.

It has also been significantly expanded.  Please review.  I'd like to
ask the security ADs for an IETF Last Call on this I-D soon.

Nico
-- 

Date: Mon, 14 Aug 2006 20:36:10 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: CRAM-MD5 applicability statement
Sender: [email-masked]

At IETF#66, I agreed to suggest text for a CRAM-MD5 applicability
statement suitable for inclusion in draft-ietf-sasl-crammd5-07.

  The CRAM-MD5 mechanism is intended to have limited use on the
  Internet.  The mechanism offers inadequate protection against
  common attacks against application-level protocols (see the
  Security Considerations section) and is prone to interoperability
  problems (see Interoperability Considerations section). Designers 
  considering profiling use of this mechanism in their
  application-level protocols should consider alternative
  mechanisms intended for common use, such as DIGEST-MD5.

As indicated by my above suggestion, I see the need to add a
section that discusses known interoperability issues, such as
those due to incompatible character sets/normalizations/encodings.

I also suggest starting the security consideration section with
a brief introductory paragraph that reenforces the position that
mechanism offers inadequate protection.  It would be good to
conclude the section with yet another reenforcing statement.

I am also concerned by the inclusion of the last paragraph of
security consideration section.  As most mechanisms, including
DIGEST-MD5, that provide data security services do so
as an elective service, the example seems flawed.  But more
importantly, I would think that data integrity protective
services would likely be needed in deployments of an "amateur
radio service", and CRAM-MD5 offers none.  Data integrity
protective services do not "obscure communications".

I'm also concerned that the first paragraph seems to dismiss
(or can easily be read as dismissing) the concerns of the
consensus of the WG, if not the IETF.

-- Kurt

Date: Fri, 11 Aug 2006 02:00:46 -0500
From: Nicolas Williams <[email-masked]>
To: Tom Yu <[email-masked]>
Cc: [email-masked]
Subject: Re: draft minutes SASL WG @ IETF66
Mail-Followup-To: Tom Yu <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Aug 10, 2006 at 11:56:49PM -0400, Tom Yu wrote:
> GS2:
> ====
> 
> Simon Josefsson leads discussion via Jabber
> 
> Main open issue is channel bindings.  Sam and others feel that channel
> bindings to TLS should be specified in a general way and not in this
> document and not in this WG.  Nico kind of has an individual
> submission relating to this.  TLS PRF is probably the way to handle
> channel bindings.  Lengthy discussion about whether TLS
> implementations provide access to PRF, also whether to use some hash
> of TLS finished messages.

draft-williams-on-channel-binding-00.txt was submitted today.

It replaces draft-ietf-nfsv4-channel-bindings-03.txt.

Neither was in the I-D repository at the time of IETF66 however :)

Nico
-- 

To: [email-masked]
Subject: draft minutes SASL WG @ IETF66
From: Tom Yu <[email-masked]>
Date: Thu, 10 Aug 2006 23:56:49 -0400
Lines: 124
Sender: [email-masked]

I have uploaded these draft minutes to the Meeting Materials page.
Please comment if you think there should be corrections to these
minutes.  Also, please respond if you have objections or comments on
the consensus points and updated milestones.  Thanks.

---Tom

Simple Authentication and Security Layer (SASL) WG
IETF 66
Monday, July 10, 2006, at 1520-1720

Chairs:
Tom Yu <[email-masked]>
Kurt Zeilenga <[email-masked]>

====================

Thanks to Jeffrey Hutzelman for scribing.

Agenda slides:
http://www3.ietf.org/proceedings/06jul/slides/sasl-1.pdf

GS2 slides:
http://www3.ietf.org/proceedings/06jul/slides/sasl-0.pdf

Summary of consensus points and action items:
=============================================

DIGEST-MD5: AES cipher IV / QOP data?  Add to nonce like channel bindings.
DIGEST-MD5: "SHOULD" vs "MUST" check authzid?  Use non-normative text.
DIGEST-MD5: AES not RC4 is mandatory to implement.

CRAM-MD5: Kurt will write applicability statement.

Updated Milestones:

Aug 2006 WGLC for CRAM-MD5
Aug 2006 WGLC for GS2
Aug 2006 WGLC for DIGEST-MD5
Sep 2006 CRAM-MD5 to IESG
Sep 2006 GS2 to IESG
Sep 2006 DIGEST-MD5 to IESG
Oct 2006 Implementation report plan
Nov 2006 Revise charter or conclude

Document Status:
================

CRAM-MD5 - needs applicability statement
GS2 - some open issues
GSSAPI - sent to IESG
PLAIN - approved
rfc2831bis (DIGEST-MD5) - some open issues

DIGEST-MD5:
===========

Alexey talks about DIGEST-MD5

AES cipher IV - DIGEST-MD5 suffers from some MITM attacks because hash
doesn't include QOP attributes generated by both ends.  With new AES
cipher, we can fix it in the new cipher spec.  In previous
conversation with Sam, he pointed out that if both ends are using the
AES cipher, they've already negotiated confidentiality, which is the
strongest mode.  He then suggests that we can get protection for QOP
by adding data to channel bindings.  Following a question from Kurt,
Alexey clarifies that QOP data would be added to the nonce in the same
way that channel bindings would be.  No objections.

Use of different string preparations - the 09 revision added new way
to describe what preps are supported by server; client picks one.
After a previous discussion, proposal to deal with both old and new
implementations by defining a new attribute to indicate that server
supports saslprep.  When client sees the attribute, it sends one hash
each for the saslprep string and the unprepared string.  Some debate
about optimization to only send one string if they're identical.  Sam
warns to be careful to consider implications for testing.

Simon (via Jabber) raises concerns about apps area intentions to
revisit stringprep.  John Klensin is summoned to Jabber.  John
comments that it's unknown to what degree SASLprep will be impacted.
Most of the issue is whether stringprep is tied to a particular
version of Unicode; if it's not, then there might be differences in
normalization and hence problems with forward compatibility.  Sam is
primarily concerned about linguistically valid text, which will
probably be less of an issue, but John points out that some
non-linguistically valid text makes really good identifiers and
passwords, and there could be trouble if Unicode version changes
affect the normalization.

Re-authentication differences between HTTP DIGEST and DIGEST-MD5?
DIGEST-MD5 requires client side nonce to be same on re-auth while HTTP
DIGEST doesn't have this restriction.  Do we care?  Should we make
them the same?  Security issues one way or other?  Check with ekr.

"SHOULD" vs "MUST" verify authorization ID?  It's really up to the
application profile; will revise to use non-normative form.

AES mandatory to implement?  Simon had pointed out some problems with
RC4.  Any objections to AES counter mode mandatory?  No objections.

The document uses HTTP ABNF which has extra constructs from standard
ABNF; linear whitespace differences, etc.  Removing pieces of HTTP
ABNF which were in common with standard ABNF.  Some coordination
possible with HTTP people; HTTP ABNF might become a separate document.

CRAM-MD5:
=========

Sam sees no applicability statement in latest CRAM-MD5 draft; Kurt
will write one.

GS2:
====

Simon Josefsson leads discussion via Jabber

Main open issue is channel bindings.  Sam and others feel that channel
bindings to TLS should be specified in a general way and not in this
document and not in this WG.  Nico kind of has an individual
submission relating to this.  TLS PRF is probably the way to handle
channel bindings.  Lengthy discussion about whether TLS
implementations provide access to PRF, also whether to use some hash
of TLS finished messages.

Date: Wed, 9 Aug 2006 10:05:54 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 08, 2006 at 08:28:08PM -0400, Sam Hartman wrote:
>     Nicolas> I'll submit the On Channel Bindings draft this week.
> 
>     Nicolas> BTW, does this mean that that draft has to be normative
>     Nicolas> for GS2 et. al., and so Standards-Track?
> 
> Yes.
> 
> Have you coordinated with nfsv4 or do I need to do that and let them
> know we're taking it out of nfs?

Done.

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings) 
Date: Wed, 09 Aug 2006 07:51:54 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:
> Will referencing 'finished messages' in RFC 4346 for channel bindings
> do the right thing when this is fixed in TLS?
> 
> If not, maybe we do need to discuss versioning of channel bindings, to
> support both the RFC 4346-style finished messages and whatever will be
> in RFC 4346bis to solve the MD5/SHA1 issue.

Huh?

If you reference the Finished messages, you will get whatever
Finished messages the particular version of TLS uses. If it's
4346 you'll get the combined MD5/SHA-1 ones. If it's TLS 1.2
you'll get the new ones. 

-Ekr

From: Simon Josefsson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 09 Aug 2006 16:46:43 +0200
Sender: [email-masked]

Eric Rescorla <[email-masked]> writes:

> Simon Josefsson <[email-masked]> wrote:
>
>> Eric Rescorla <[email-masked]> writes:
>> 
>> > Simon Josefsson <[email-masked]> wrote:
>> >> >> In the specific case of TLS, hashing the finished messages would one
>> >> >> way to get a suitable TLS channel binding.
>> >> >
>> >> > No, no hashing -- that leads to hash agility issues.  Thus my suggestion
>> >> > of a MIC, but I'd rather avoid that.
>> >> 
>> >> There is also an implicit hash agility issue in using the TLS finished
>> >> messages, since the finished message are hard-coded to use MD5 and
>> >> SHA1 today.  I'm not sure how this hash agility problem will be solved
>> >> in TLS, if at all.  Eric?
>> >
>> > The PRF will be dependent on the cipher suite. For most ciphersuites,
>> > it will be based on the MAC.
>> 
>> What about the hard-coded use of MD5 and SHA1?
>
> That will be fixed too.

Will referencing 'finished messages' in RFC 4346 for channel bindings
do the right thing when this is fixed in TLS?

If not, maybe we do need to discuss versioning of channel bindings, to
support both the RFC 4346-style finished messages and whatever will be
in RFC 4346bis to solve the MD5/SHA1 issue.

/Simon

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings) 
Date: Wed, 09 Aug 2006 07:26:17 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:

> Eric Rescorla <[email-masked]> writes:
> 
> > Simon Josefsson <[email-masked]> wrote:
> >> >> In the specific case of TLS, hashing the finished messages would one
> >> >> way to get a suitable TLS channel binding.
> >> >
> >> > No, no hashing -- that leads to hash agility issues.  Thus my suggestion
> >> > of a MIC, but I'd rather avoid that.
> >> 
> >> There is also an implicit hash agility issue in using the TLS finished
> >> messages, since the finished message are hard-coded to use MD5 and
> >> SHA1 today.  I'm not sure how this hash agility problem will be solved
> >> in TLS, if at all.  Eric?
> >
> > The PRF will be dependent on the cipher suite. For most ciphersuites,
> > it will be based on the MAC.
> 
> What about the hard-coded use of MD5 and SHA1?

That will be fixed too.

-Ekr

From: Simon Josefsson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 09 Aug 2006 11:01:59 +0200
Sender: [email-masked]

Eric Rescorla <[email-masked]> writes:

> Simon Josefsson <[email-masked]> wrote:
>> >> In the specific case of TLS, hashing the finished messages would one
>> >> way to get a suitable TLS channel binding.
>> >
>> > No, no hashing -- that leads to hash agility issues.  Thus my suggestion
>> > of a MIC, but I'd rather avoid that.
>> 
>> There is also an implicit hash agility issue in using the TLS finished
>> messages, since the finished message are hard-coded to use MD5 and
>> SHA1 today.  I'm not sure how this hash agility problem will be solved
>> in TLS, if at all.  Eric?
>
> The PRF will be dependent on the cipher suite. For most ciphersuites,
> it will be based on the MAC.

What about the hard-coded use of MD5 and SHA1?

      struct {
          opaque verify_data[12];
      } Finished;

      verify_data
          PRF(master_secret, finished_label, MD5(handshake_messages) +
          SHA-1(handshake_messages)) [0..11];

If we re-use the finished messages for channel bindings in GS2, we
seem to create a situation where we depend on hard-coded
non-negotiable use of MD5/SHA1.

/Simon

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 09 Aug 2006 10:40:23 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> Another matter: I wonder if we ever will need a way to negotiate the
>> kind of channel binding used.
>
> I don't think so.  The channel has to be established first, before GS2
> can be used (OK, we could have a half-round-trip-to-setup channel, I
> suppose), so that the apps on both sides know what type of channel it is
> and so what channel binding to use.

Will applications always know which channel is intended?  For GS2 over
TLS over SSH over IPSEC, what is the channel binding?  If the TLS
channel provides poor security (e.g., no client/server-authentication
or weak privacy layer), it may make sense to bind against the SSH or
IPSEC channel instead.  One solutions is to bind to all channels.

Regarding the issue with integrity-only layers, I think we should wait
with adding more text regarding channel bindings to GS2 until there is
a channel binding document to review and reference.

If man-power is the issue, I can update my channel binding proposal
http://www.ietf.org/internet-drafts/draft-josefsson-sasl-tls-cb-00.txt
to align with the latest discussions.

/Simon

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Date: Tue, 08 Aug 2006 20:30:06 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Isn't it simpler and better to design channel bindings so
    Simon> they aren't subject to security considerations at all?  If
    Simon> we define channel bindings so they don't reveal any
    Simon> information to an attacker, we wouldn't care how they are
    Simon> transported.

Yes and unless we find we are unable to do this, we should do so.

--Sam

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Date: Tue, 08 Aug 2006 20:28:08 -0400
Sender: [email-masked]

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Aug 08, 2006 at 05:43:29PM -0400, Sam Hartman
    Nicolas> wrote:
    >> GS2 should do whatever the channel bindings draft says it
    >> should do.  Full stop.

    Nicolas> I'll submit the On Channel Bindings draft this week.

    Nicolas> BTW, does this mean that that draft has to be normative
    Nicolas> for GS2 et. al., and so Standards-Track?

Yes.

Have you coordinated with nfsv4 or do I need to do that and let them know we're taking it out of nfs?

Date: Tue, 8 Aug 2006 17:10:55 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 08, 2006 at 05:43:29PM -0400, Sam Hartman wrote:
> GS2 should do whatever the channel bindings draft says it should do.
> Full stop.

I'll submit the On Channel Bindings draft this week.

BTW, does this mean that that draft has to be normative for GS2 et. al.,
and so Standards-Track?

Date: Tue, 8 Aug 2006 16:50:49 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 08, 2006 at 11:19:25PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[email-masked]> writes:
> > Sufficiently narrow text about this would fine.  My suggestion:
> >
> >    GS2 does not provide confidentiality protection to channel bindings
> >    data.  When GS2 is used over channels that provide confidentiality
> >    protection then there is no security consideration associated with
> >    sending the channel bindings without confidentiality protection.
> >
> >    On the other hand, when GS2 is used over channels that provide only
> >    integrity protection then there may be a security consideration
> >    associated with binding SASL/GS2 authentication to such channels.
> >    See the specifications of the channel bindings data for such channels
> >    for more information.
> >
> >    In the specific case of TLS [TLS], because the channel bindings
> >    happen to be data which would be available to eavesdroppers when
> >    confidentiality protection is not used at the TLS layer, there is no
> >    further security consideration associated with GS2 and TLS channel
> >    bindings.
> 
> Isn't it simpler and better to design channel bindings so they aren't
> subject to security considerations at all?  If we define channel
> bindings so they don't reveal any information to an attacker, we
> wouldn't care how they are transported.

We're talking about the GS2 doc.  The GS2 doc should not concern itself
with world peace.

> Another matter: I wonder if we ever will need a way to negotiate the
> kind of channel binding used.

I don't think so.  The channel has to be established first, before GS2
can be used (OK, we could have a half-round-trip-to-setup channel, I
suppose), so that the apps on both sides know what type of channel it is
and so what channel binding to use.

> > No, no hashing -- that leads to hash agility issues.  Thus my suggestion
> > of a MIC, but I'd rather avoid that.
> 
> There is also an implicit hash agility issue in using the TLS finished
> messages, since the finished message are hard-coded to use MD5 and
> SHA1 today.  I'm not sure how this hash agility problem will be solved
> in TLS, if at all.  Eric?

That's someone else's problem.  We're talking about GS2 here.  I'd not
want to create a hash agility issue in GS2.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Date: Tue, 08 Aug 2006 17:43:29 -0400
Sender: [email-masked]

Can we just agree that channel bindings need to be public and be done
with it?

This discussion is way out of scope for SASL and GS2.

GS2 should do whatever the channel bindings draft says it should do.
Full stop.

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings) 
Date: Tue, 08 Aug 2006 14:30:34 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:
> >> In the specific case of TLS, hashing the finished messages would one
> >> way to get a suitable TLS channel binding.
> >
> > No, no hashing -- that leads to hash agility issues.  Thus my suggestion
> > of a MIC, but I'd rather avoid that.
> 
> There is also an implicit hash agility issue in using the TLS finished
> messages, since the finished message are hard-coded to use MD5 and
> SHA1 today.  I'm not sure how this hash agility problem will be solved
> in TLS, if at all.  Eric?

The PRF will be dependent on the cipher suite. For most ciphersuites,
it will be based on the MAC.

-Ekr

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 08 Aug 2006 23:19:25 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Aug 08, 2006 at 09:33:57PM +0200, Simon Josefsson wrote:
>> 
>> Nicolas Williams <[email-masked]> writes:
>> 
>> > In the specific case of TLS that would be a non-issue anyways -- the
>> > channel bindings (finished messages) would already go out in the clear
>> > before GS2 comes in the picture.
>> 
>> No, they are not sent in the clear, see RFC 4346:
>
> The paragraph you did not quote said: "We do need to discuss the
> security of channel bindings vis-a-vis eavesdroppers for channels that
> provide only integrity protection, but this is, IMO, beyond the scope of
> GS2."
>
> The paragraph you quoted referred to channels that provide only
> integrity protection.  In the specific case of TLS with integrity
> protection only then the finished messages are only integrity-protected.

Oh, right, I see.

>> The draft could say that, in general, channel binding data should not
>> be security sensitive, and then it follows that it isn't a problem to
>> send them in only integrity protected channels.
>
> Sufficiently narrow text about this would fine.  My suggestion:
>
>    GS2 does not provide confidentiality protection to channel bindings
>    data.  When GS2 is used over channels that provide confidentiality
>    protection then there is no security consideration associated with
>    sending the channel bindings without confidentiality protection.
>
>    On the other hand, when GS2 is used over channels that provide only
>    integrity protection then there may be a security consideration
>    associated with binding SASL/GS2 authentication to such channels.
>    See the specifications of the channel bindings data for such channels
>    for more information.
>
>    In the specific case of TLS [TLS], because the channel bindings
>    happen to be data which would be available to eavesdroppers when
>    confidentiality protection is not used at the TLS layer, there is no
>    further security consideration associated with GS2 and TLS channel
>    bindings.

Isn't it simpler and better to design channel bindings so they aren't
subject to security considerations at all?  If we define channel
bindings so they don't reveal any information to an attacker, we
wouldn't care how they are transported.

Another matter: I wonder if we ever will need a way to negotiate the
kind of channel binding used.

One way to achieve that negotiation is to require that channel
bindings are sent over the wire (as in GS2), and disallow designs
where the protocols compare them against a hash on each side, and then
prefix the channel binding data with an identifier.  For example, the
channel binding could be "tls-cb-v0:[tls finished messages]".  A
receiver could understand both "tls-cb-v0" and "tls-cb-v1", and pick
the appropriate scheme based on the specifications of tls-cb-v0 or
tls-cb-v1.

If we don't require that the channel binding must be sent over the
wire (I'd prefer this), I don't see any options but to negotiate the
channel binding revision in the security protocol (e.g., in a TLS
extension, for TLS) or in the protocol using channel bindings (e.g.,
GS2).

>> In the specific case of TLS, hashing the finished messages would one
>> way to get a suitable TLS channel binding.
>
> No, no hashing -- that leads to hash agility issues.  Thus my suggestion
> of a MIC, but I'd rather avoid that.

There is also an implicit hash agility issue in using the TLS finished
messages, since the finished message are hard-coded to use MD5 and
SHA1 today.  I'm not sure how this hash agility problem will be solved
in TLS, if at all.  Eric?

/Simon

Date: Tue, 8 Aug 2006 15:18:43 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Sam Hartman <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Simon Josefsson <[email-masked]>, Sam Hartman <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 08, 2006 at 09:33:57PM +0200, Simon Josefsson wrote:
> 
> Nicolas Williams <[email-masked]> writes:
> 
> > In the specific case of TLS that would be a non-issue anyways -- the
> > channel bindings (finished messages) would already go out in the clear
> > before GS2 comes in the picture.
> 
> No, they are not sent in the clear, see RFC 4346:

The paragraph you did not quote said: "We do need to discuss the
security of channel bindings vis-a-vis eavesdroppers for channels that
provide only integrity protection, but this is, IMO, beyond the scope of
GS2."

The paragraph you quoted referred to channels that provide only
integrity protection.  In the specific case of TLS with integrity
protection only then the finished messages are only integrity-protected.

> The draft could say that, in general, channel binding data should not
> be security sensitive, and then it follows that it isn't a problem to
> send them in only integrity protected channels.

Sufficiently narrow text about this would fine.  My suggestion:

   GS2 does not provide confidentiality protection to channel bindings
   data.  When GS2 is used over channels that provide confidentiality
   protection then there is no security consideration associated with
   sending the channel bindings without confidentiality protection.

   On the other hand, when GS2 is used over channels that provide only
   integrity protection then there may be a security consideration
   associated with binding SASL/GS2 authentication to such channels.
   See the specifications of the channel bindings data for such channels
   for more information.

   In the specific case of TLS [TLS], because the channel bindings
   happen to be data which would be available to eavesdroppers when
   confidentiality protection is not used at the TLS layer, there is no
   further security consideration associated with GS2 and TLS channel
   bindings.

> In the specific case of TLS, hashing the finished messages would one
> way to get a suitable TLS channel binding.

No, no hashing -- that leads to hash agility issues.  Thus my suggestion
of a MIC, but I'd rather avoid that.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 08 Aug 2006 21:33:57 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> In the specific case of TLS that would be a non-issue anyways -- the
> channel bindings (finished messages) would already go out in the clear
> before GS2 comes in the picture.

No, they are not sent in the clear, see RFC 4346:

7.4.9. Finished
...
      The finished message is the first protected with the just-
      negotiated algorithms, keys, and secrets.

> The general case I think this needs to be covered in the "On Channel
> Binding" draft.

Agreed.

The draft could say that, in general, channel binding data should not
be security sensitive, and then it follows that it isn't a problem to
send them in only integrity protected channels.

In the specific case of TLS, hashing the finished messages would one
way to get a suitable TLS channel binding.

> We could decide to MIC the channel bindings and avoid further
> discussion.  I'd be happy with that.

If you change "channel bindings" to "finished messages", I'd agree.

I don't see a need to MIC channel bindings in general.  Revealing
channel bindings shouldn't be a security issue.

/Simon

Date: Tue, 8 Aug 2006 13:29:53 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Sender: [email-masked]

We do need to discuss the security of channel bindings vis-a-vis
eavesdroppers for channels that provide only integrity protection, but
this is, IMO, beyond the scope of GS2.

In the specific case of TLS that would be a non-issue anyways -- the
channel bindings (finished messages) would already go out in the clear
before GS2 comes in the picture.

The general case I think this needs to be covered in the "On Channel
Binding" draft.

We could decide to MIC the channel bindings and avoid further
discussion.  I'd be happy with that.

Nico
-- 

Date: Tue, 8 Aug 2006 12:45:24 -0500
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Sam Hartman <[email-masked]>, Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Aug 08, 2006 at 01:00:09PM -0400, Sam Hartman wrote:
> Note that gs2 does make the channel bindings visible to a potential
> man in the middle.  However that is OK if the channel bindings are
> designed properly.

Sam, for Pete's sakes!  The MITM already would know the channel
bindings.

GS2 does not leak channel bindings data to any peer that shouldn't
already know the channel bindings -- provided that GS2 is run over the
channel being bound to, of course.

Nico
-- 

From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Date: Tue, 08 Aug 2006 13:00:09 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> I thought we agreed that channel binding data should be
    Simon> designed so they aren't security sensitive, and in that
    Simon> case, the threat model permits attackers to access the
    Simon> finished messages.  The GS2 protocol doesn't need to leak
    Simon> them.

Agreed.

    Simon> In other words, whether the GS2 protocol leaks the channel
    Simon> binding data doesn't matter.  By designing channel bindings
    Simon> as security insensitive, we should not be worried if
    Simon> attackers get hold of them.
Agreed.

    Simon> Presumably, other protocols than GS2 may use channel
    Simon> bindings too, and leaking the channel binding messages in
    Simon> those protocols should not be a problem, if channel
    Simon> bindings are designed properly.

Also agreed.

Note that gs2 does make the channel bindings visible to a potential
man in the middle.  However that is OK if the channel bindings are
designed properly.

--Sam

Date: Mon, 7 Aug 2006 15:26:31 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Aug 07, 2006 at 02:38:07PM -0500, Nicolas Williams wrote:
> On Mon, Aug 07, 2006 at 08:57:34PM +0200, Simon Josefsson wrote:
> > I thought we agreed that channel binding data should be designed so
> > they aren't security sensitive, and in that case, the threat model
> > permits attackers to access the finished messages.  The GS2 protocol
> > doesn't need to leak them.
> 
> I never said that, and GS2, as long as it's run inside the channel being
                   ^
		   in this thread
> bound to, doesn't leak anything at all about channel bindings to any
> party that didn't already have access to the information being leaked.

Date: Mon, 7 Aug 2006 14:38:07 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Aug 07, 2006 at 08:57:34PM +0200, Simon Josefsson wrote:
> 
> Nicolas Williams <[email-masked]> writes:
> 
> >> In this thread -- which I believe was very useful -- I didn't see a
> >> proof that the TLS finished messages are useless to someone who is
> >> attacking the TLS channel.  Thus, a security consideration along the
> >> lines of:
> >
> > In no circumstance in GS2 are the finished messages made visible to any
> > party that doesn't already know what they are, thus there is no security
> > consideration like you suggest.
> 
> I thought we agreed that channel binding data should be designed so
> they aren't security sensitive, and in that case, the threat model
> permits attackers to access the finished messages.  The GS2 protocol
> doesn't need to leak them.

I never said that, and GS2, as long as it's run inside the channel being
bound to, doesn't leak anything at all about channel bindings to any
party that didn't already have access to the information being leaked.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 07 Aug 2006 20:57:34 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> In this thread -- which I believe was very useful -- I didn't see a
>> proof that the TLS finished messages are useless to someone who is
>> attacking the TLS channel.  Thus, a security consideration along the
>> lines of:
>
> In no circumstance in GS2 are the finished messages made visible to any
> party that doesn't already know what they are, thus there is no security
> consideration like you suggest.

I thought we agreed that channel binding data should be designed so
they aren't security sensitive, and in that case, the threat model
permits attackers to access the finished messages.  The GS2 protocol
doesn't need to leak them.

In other words, whether the GS2 protocol leaks the channel binding
data doesn't matter.  By designing channel bindings as security
insensitive, we should not be worried if attackers get hold of them.

Presumably, other protocols than GS2 may use channel bindings too, and
leaking the channel binding messages in those protocols should not be
a problem, if channel bindings are designed properly.

I agree that the GS2 protocol doesn't make the channel binding visible
to anyone else.  (Except possibly if a weird GSS-API mechanism send
GSS_Wrap tokens out-of-band; the conf_flag is FALSE in the GSS_Wrap
call after all.  But I'm not sure whether the GSS-API framework
permits such mechanisms.)

Eric didn't see a problem with leaking TLS finished messages, but,
with respect, that is not the same as a proof that there isn't a
problem.  If we can't prove the property, and if even readers like
Eric become "a bit nervous" and has to think about it, adding a
security consideration seems appropriate.  (Or run the finished
messages through a hash before using them as a channel binding.)

/Simon

Date: Mon, 7 Aug 2006 10:13:19 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
Mail-Followup-To: Simon Josefsson <[email-masked]>, Eric Rescorla <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sun, Aug 06, 2006 at 11:20:29AM +0200, Simon Josefsson wrote:
> Yes, I believe so, with the qualification that it has to be the first
> pair of finished messages in a particular session, and for resumed
> sessions, we use the first pair of finished messages in that
> particular resumed session.

Of course.

> In this thread -- which I believe was very useful -- I didn't see a
> proof that the TLS finished messages are useless to someone who is
> attacking the TLS channel.  Thus, a security consideration along the
> lines of:

In no circumstance in GS2 are the finished messages made visible to any
party that doesn't already know what they are, thus there is no security
consideration like you suggest.

>   This design assumes that knowledge of the TLS finished messages for
>   a particular channel does not help an attacker of that TLS channel.

No, it doesn't.

> > Also, please reference draft-altman-tls-channel-bindings-00.txt.
> 
> I cannot find that document.

Jeff?

Nico
-- 

To: Simon Josefsson <[email-masked]>
cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings) 
Date: Sun, 06 Aug 2006 12:41:44 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Simon Josefsson <[email-masked]> wrote:

> Nicolas Williams <[email-masked]> writes:
> 
> > On Mon, Jul 31, 2006 at 01:13:57PM -0700, Eric Rescorla wrote:
> >> > > It had better not, since they're sent in the clear in the NULL_MD5
> >> > > and NULL_SHA1 cipher suites.
> >> > 
> >> > Also, it's supposed to be a one-way function, is it not?  
> >> 
> >> Yep.
> >> 
> >> It's just that that's a constructive argument. I thought a pseudo-reduction
> >> might be more uh... motivating.
> >
> > So, can we declare consensus: that we'll use the [cleartext] TLS
> > finished messages as the channel bindings for TLS sessions?
> 
> Yes, I believe so, with the qualification that it has to be the first
> pair of finished messages in a particular session, and for resumed
> sessions, we use the first pair of finished messages in that
> particular resumed session.
> 
> In this thread -- which I believe was very useful -- I didn't see a
> proof that the TLS finished messages are useless to someone who is
> attacking the TLS channel.  Thus, a security consideration along the
> lines of:
> 
>   This design assumes that knowledge of the TLS finished messages for
>   a particular channel does not help an attacker of that TLS channel.
> 
> This is the part that has been worrying me, but if the consensus is
> that this assumption is unproblematic, I'd satisfied with a security
> consideration.

I've spent some time thinking about this and don't see a problem--though
it does make me a bit nervous. However, as I said, if there is one then
all of the NULL algorithms have problems. I think what would be best
here would be to require that the Finished messages be put once more
through a one-way function.

-Ekr

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: GS2 update
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 06 Aug 2006 11:37:41 +0200
Sender: [email-masked]

If the channel binding issue is closed, I believe GS2 -02, as
announced below, is ready for WGLC.  Did I miss any open issue?

The draft currently reference Nico's document for TLS channel
bindings, but I think we can update the reference later on if it turns
out that channel bindings will be defined in another document.  Or do
we have to wait for this new document, and change the reference in
GS2, before a WGLC?

/Simon

Simon Josefsson <[email-masked]> writes:

> Hi All,
>
> I've asked for GS2 -02 to be published, review it here until it shows
> up in the repository:
>
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
>
> The changes are in:
>
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-02-from-1.diff.html
>
> In particular:
>
>  * Simplified channel bindings, new section 5 below.
>
>    - This moves the (still) open issue of how to define channel
>      binding syntax to Nico's draft
>
>  * Added example of channel binding connection
>
>  * Clarified how the security layer bit mask works
>
> Can I ask that somebody independently compute the example GS2
> mechanism name for SPKM?  This is what I got:
>
>    For example, the OID for the SPKM-1 mechanism [13] is
>    1.3.6.1.5.5.1.1.  The ASN.1 DER encoding of the OID is 06 07 2b 06 01
>    05 05 01 01.  The SHA-1 hash of the ASN.1 DER encoding is
>    1cf8f42b5a9f80fae9f831226d5d9d56278661ad.  The Base32 encoding of the
>    first ten bytes of this is "DT4PIK22T6EPV2PY".  Thus the SASL
>    mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-
>    DT4PIK22T6EPV2PY".
>
> I believe this version is ready for WGLC.
>
> /Simon
>
> 5.  Channel Bindings
>
>    The GS2 mechanism provide its own channel binding mechanism, instead
>    of using the "chan_binding" parameter in the GSS-API context
>    functions.  The reason for this is that the GS2 mechanism provide an
>    option to proceed even if the channel bindings does not match.  The
>    GSS-API framework specifies that authentication cannot proceed if
>    channel bindings does not match.
>
>    Client and servers MUST set the "chan_binding" parameter in the calls
>    to GSS_Init_sec_context to GSS_Accept_sec_context, respectively, to
>    NULL.
>
>    Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
>    no security layer and instead depend on the session security afforded
>    by the bound-in channel.
>
>    Use of no SASL security layers in combination with channel binding
>    should provide better performance than using SASL security layers
>    over secure channels, and better security characteristics than using
>    no SASL security layers over secure channels without channel binding.
>
>    For more discussions of channel bindings, and the syntax of the
>    channel binding data for various security protocols, see [7].

From: Simon Josefsson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Consensus (Re: TLS channel bindings)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 06 Aug 2006 11:20:29 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Mon, Jul 31, 2006 at 01:13:57PM -0700, Eric Rescorla wrote:
>> > > It had better not, since they're sent in the clear in the NULL_MD5
>> > > and NULL_SHA1 cipher suites.
>> > 
>> > Also, it's supposed to be a one-way function, is it not?  
>> 
>> Yep.
>> 
>> It's just that that's a constructive argument. I thought a pseudo-reduction
>> might be more uh... motivating.
>
> So, can we declare consensus: that we'll use the [cleartext] TLS
> finished messages as the channel bindings for TLS sessions?

Yes, I believe so, with the qualification that it has to be the first
pair of finished messages in a particular session, and for resumed
sessions, we use the first pair of finished messages in that
particular resumed session.

In this thread -- which I believe was very useful -- I didn't see a
proof that the TLS finished messages are useless to someone who is
attacking the TLS channel.  Thus, a security consideration along the
lines of:

  This design assumes that knowledge of the TLS finished messages for
  a particular channel does not help an attacker of that TLS channel.

This is the part that has been worrying me, but if the consensus is
that this assumption is unproblematic, I'd satisfied with a security
consideration.

Interaction with the TLS/IA extension may need further specification
too, but I'd count that as one problem (one out of many) with the
TLS/IA extension.

> Also, please reference draft-altman-tls-channel-bindings-00.txt.

I cannot find that document.

/Simon

Date: Tue, 01 Aug 2006 10:15:02 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: AD Review for draft-ietf-sasl-gssapi-xx.txt
Sender: [email-masked]

Sam Hartman wrote:

>Hi.
>
>In general draft-ietf-sasl-gssapi-xx looks reasonably good, although a
>few issues need to be fixed and the document reissued before I can
>last call it.
>
>
>What happened to the spnego mechanism name (gss-spnego? or something
>like that?)  It is reasonably widely deployed and I thought was
>documented here.
>  
>
I think Kurt has answered this question.

>The document fails to meet a few requirements of section 5 of RFC 4422:
>
>      b) An indication of whether the server is expected to provide
>         additional data when indicating a successful outcome.  If so,
>         if the server sends the additional data as a challenge, the
>  
>
I think this can be deducted from the fact that the last data packet is 
directed from client to the server.

However in order to clarify this I suggest adding to the end of "3.2.  
Server side of authentication protocol exchange", after the following 
sentence:

  After these verifications, the authentication process is complete.

the following sentence:

  The server is not expected to return any additional data with the 
success indicator.

>   5) If the underlying cryptographic technology used by a mechanism
>         supports data integrity, then the mechanism specification MUST
>         integrity protect the transmission of an authorization identity
>         and the negotiation of the security layer.
>
>                     
>I think the resolution here is to always require the integrity flag be
>set.
>  
>
You mean passing integ_req_flag=true to GSS_Init_sec_context?

This would be fine with me, however this is not the existing practice 
(e.g. Cyrus SASL only passes this flag when it also negotiates the SASL 
security layer with integrity protection).

>I believe the following text may be generally false for gssapi
>mechanisms and is certainly false for RFC 4121.  I think it is false
>for 1964 if a client asserts a subkey.
>
>
>   The integrity protection provided by the GSSAPI security layer is
>   useless to the client unless the client also requests mutual
>   authentication.  Therefore, a client wishing to benefit from the
>   integrity protection of a security layer MUST pass to the
>   GSS_Init_sec_context call a mutual_req_flag of TRUE.
>
>In particular I think SASL's use of gssapi will get it mutual auth
>regardless of whether it requests mutual auth.
>  
>
Do you recommend to remove the quoted paragraph?

>The text in section 3 recommends that servers check the name the
>client authenticated to.  If the server passes in GSS_C_NO_CREDENTIAL
>(or acquires credentials with no name) this seems desirable.  However
>I don't understand why it is desirable if the server passed in a name
>for its credentials.
>  
>
That is one of the reasons why the requirement to do this is a SHOULD. I 
was trying to have a single sentence that covered all different cases 
for the server.
This didn't work very well. Ok, here is the updated sentence:

Upon successful establishment of the security context
and if the server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create 
acceptor credential handle,
the server SHOULD also check using the GSS_Inquire_context that the 
target_name used by the client
matches either:

So basically I've added "and if the server used 
GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor credential handle".

Alexey