Subject: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)

From: The IESG <[email-masked]>
Date: Mon, 28 Aug 2006 16:18:14 -0400

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

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Aug 2006 16:46:51 -0500

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
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Aug 2006 18:03:16 -0400

>>>>> "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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Aug 2006 17:45:10 -0500

On Mon, Aug 28, 2006 at 03:33:45PM -0700, Mark Crispin wrote:
> On Mon, 28 Aug 2006, Nicolas Williams wrote:
> >>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
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Aug 2006 17:50:00 -0500

On Mon, Aug 28, 2006 at 03:21:18PM -0700, Mark Crispin wrote:
> On Mon, 28 Aug 2006, Sam Hartman wrote:
> The "I believe" part scares me.

Are you kidding?

Nico
--

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Aug 2006 13:39:42 -0700 (Pacific Daylight Time)

-- Mark --

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Aug 2006 15:21:18 -0700 (Pacific Daylight Time)

> implementations tend to provide integrity even when it is not

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.

> willing to take the document to the IESG unless integ_flag remains a

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.]

> especially interested in cases where this change creates a wire

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 --

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Aug 2006 15:33:45 -0700 (Pacific Daylight Time)

>> 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.

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 --

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Aug 2006 16:04:53 -0700 (Pacific Daylight Time)

> 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.

> 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).

> probable, and, anyways, your claims of compliance would do nothing for

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 --

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Aug 2006 16:09:18 -0700 (Pacific Daylight Time)

>> The "I believe" part scares me.

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 --

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 28 Aug 2006 16:14:19 -0700

>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.

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Aug 2006 14:54:51 -0700 (Pacific Daylight Time)

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.

> bindings..." and "[w]hen non-NULL channel bindings are provided").

OK, consider that one withdrawn.  Thanks.

-- Mark --

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Aug 2006 17:08:20 -0500

> 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.

Nico
--

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 28 Aug 2006 17:43:09 -0700

At 04:20 PM 8/28/2006, Mark Crispin wrote:
>On Mon, 28 Aug 2006, Kurt D. Zeilenga wrote:
>Doesn't that depend upon the GSSAPI implementation? 

As indicated by my comments, yes.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Aug 2006 21:27:07 -0400

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> 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.

    >> especially interested in cases where this change creates a wire

    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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Aug 2006 16:20:24 -0700 (Pacific Daylight Time)

> This I-D should note the change was made and why in the Changes

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 --

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Aug 2006 15:14:19 -0400

> 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. ]

> 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

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: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 13:57:28 -0700 (Pacific Daylight Time)

On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
> 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."

> 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:

> 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 

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.

> 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 

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 --

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 29 Aug 2006 17:21:43 -0400

>     known GSSAPI 2.1 implementations treat it as set, this behavior can

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 Aug 2006 23:28:54 +0200 (MET DST)

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Aug 2006 18:16:17 -0400

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

>> 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.
>

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.

>> 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

... 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().

> 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.

> 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'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 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.
>

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.

> 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.

>> 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.
>
> 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

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.

>      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?

>      known GSSAPI 2.1 implementations treat it as set, this behavior can

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.
>

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]>
Date: Wed, 30 Aug 2006 01:55:56 +0200 (MET DST)

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

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.

> 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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 17:38:49 -0700 (Pacific Daylight Time)

On Tue, 29 Aug 2006, Jeffrey Hutzelman wrote:
> 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?

> ... 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 

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.

> 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.

> backward-compatible.  I agree that the "mostly" is unfortunate and creates an 
> increased burden for the developer of GSS-API-using applications, since 

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.

> 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.

> 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 

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.

> 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.

> 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.

> 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 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.

> 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"?

> anything that's not an implementation of this spec is not subject to the 

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 --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 17:40:15 -0700 (Pacific Daylight Time)

Martin, thank you.

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

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 17:41:47 -0700 (Pacific Daylight Time)

> 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 --

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Aug 2006 20:54:32 -0400

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

> 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

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.

> to make stupid backwards incompatible changes just for the sake

"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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Aug 2006 21:57:05 -0400

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

> 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.

> 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.

>> 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.
>
> the GSS_Sign, GSS_Verify, GSS_Seal, and GSS_Unseal interfaces for
> backward compatibility.
>

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.
>

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.

> 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.

> take place in 2000.  I object to my existing releases being labelled

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.

> incompatibility and in failing to communicate it to people who had used

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.

>> implementation and use it with a newer version of the GSS-API than was
>> used  by that document.
>
> 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.

> 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,

>> 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.
>

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.

> 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.

> 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 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.
>

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.
>

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.

>> 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.
>

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.

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Aug 2006 22:29:43 -0400

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

> 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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 19:47:10 -0700

> implementated RFC 2743/2744 instead of RFC 2078, it ceased to be compliant 

That is not an acceptable outcome.

> 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 

That's what the GSSAPI mechanism

> 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.

> 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 

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'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.

> (a) the library you are using probably sets the bit on the wire even if

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

>   seeing serious interop problems)

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

>   GSS_Unwrap correctly even if the bit was not set on the wire is

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.

> 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.

> 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.

> 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?

> 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 --

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Aug 2006 00:33:08 -0400

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

>> implementated RFC 2743/2744 instead of RFC 2078, it ceased to be
>> compliant  with RFC 2222.
>

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.
>

Huh?  Looks like something got cut out here.

>> 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 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.

> 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.

>>   GSS_Unwrap correctly even if the bit was not set on the wire is

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).

> 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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 01:12:55 -0400

>>>>> "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: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 22:20:50 -0700 (PDT)

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:

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: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 22:24:43 -0700 (PDT)

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 22:44:17 -0700 (PDT)

> It is a very good idea unless other concerns override.

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

>    Mark> enables the new stuff only between consenting

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 23:21:31 -0700 (PDT)

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.
>
> 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 

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.

> 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.

> 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.

> 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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 00:55:51 -0400

>> 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?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 00:50:09 -0400

>>>>> "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.

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Aug 2006 16:16:19 +0200 (MET DST)

> 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).

> 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

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Aug 2006 16:55:50 +0200 (MET DST)

>     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.

>     [...] 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: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 10:29:08 -0500

> 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: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 11:32:48 -0400

>>>>> "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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 10:40:59 -0500

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]>
Date: Wed, 30 Aug 2006 11:58:46 -0400

>>>>> "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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 12:00:52 -0400

>>>>> "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: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 09:19:40 -0700 (PDT)

> versioning to prevent this problem.  Similarly for other language

I agree.  But they didn't do that.

> because either: a) you screwed up, and/or b) your GSS-API implementor

(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.

> 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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 09:31:32 -0700 (PDT)

> integrity service is always available but don't actually say so.

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

> 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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 30 Aug 2006 18:41:07 +0200

> 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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 09:42:20 -0700 (PDT)

> 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.

> 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

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Aug 2006 17:04:46 +0200 (MET DST)

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 13:27:03 -0400

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 13:14:19 -0400

>>>>> "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]>
Date: Wed, 30 Aug 2006 13:12:47 -0400

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?

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Aug 2006 19:30:32 +0200 (MET DST)

> (or is) non-conforming.  I just don't think today's text says that

Updating (rev'ing) rfc-2743 will require resources, but is not going
to fix a poorly designed installed base.  Trying to get rid of
abiguity in a spec that has been there for so many years is likely
very difficult.

Right now rfc-2743 does NOT require applications to assert
integ_req_flag or conf_req_flag if they desire to use it later on,
so the SASL document should not use a MUST, but rather a SHOULD
for asserting the integ_req_flag.

There is some wording that gssapi mechanism implementors may use
as an excuse for poor design decisions breaking applications,
but there are many issue where a spec-weasel could argue why
some fancy misbehaviour (that likely breaks some apps in one
way or another) should be "OK" with the GSS-API spec.

We get regular calls from vendors asking whether creating an
interactive popup requesting input from a user from within
a gssapi function would be OK with us, and I regularly deny that--
although it is not explicitly forbidden by the GSS-API spec,
it is a pretty bad idea and will break our application (and probably
others) in several scenarios (timeout-related) and therefore we do not
allow it for "interoperability certification" with our application.

One vendor showed up with a GSS-API mechanism that unconditionally
applied confidentiality protection during gss_wrap(), even if the
application didn't ask for it.  Although this is not strictly
forbidden by GSS-API, I consider it a bad idea.

Our application can be configured to use three "protection" level
when using GSS-API: 
  - authentication only
  - data integrity protection
  - data integrity and confidentiality protection

if the second level (data integrity protection) is used, our
application uses gss_getmic/gss_verifymic and _not_ gss_wrap/gss_unwrap,
so the attempt of the gssapi mechanism to "enforce" confidentiality
during gss_wrap doesn't work.  If the first level (authentication only)
is requested, no message protection services are called by our application,
which is the most portable approach.   

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 12:36:54 -0500

> 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: Martin Rex <[email-masked]>
Date: Wed, 30 Aug 2006 19:59:41 +0200 (MET DST)

> versioning to prevent this problem.  Similarly for other language

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 12:39:16 -0500

On Wed, Aug 30, 2006 at 10:20:00AM -0700, Mark Crispin 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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Aug 2006 13:24:21 -0400

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 10:43:22 -0500

> 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
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 13:55:17 -0500

On Wed, Aug 30, 2006 at 11:35:57AM -0700, Mark Crispin wrote:
> >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
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 13:56:44 -0500

On Wed, Aug 30, 2006 at 11:48:21AM -0700, Mark Crispin wrote:
> I don't know.  Do you?

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

> 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
--

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 12:07:49 -0700 (PDT)

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 14:08:41 -0500

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

Nico
--

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 10:20:00 -0700 (PDT)

> 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?

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.

-- Mark --

http://panda.com/mrc

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 14:22:13 -0500

> 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
--

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 12:24:14 -0700 (PDT)

> 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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 11:35:57 -0700 (PDT)

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 14:31:20 -0500

> So how would this be stated in the document?

It doesn't have to be.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Aug 2006 21:30:50 +0200 (MET DST)

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 14:31:20 -0500

It doesn't have to be.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Aug 2006 21:30:50 +0200 (MET DST)

Yes, please.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 11:44:19 -0500

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?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 30 Aug 2006 22:35:11 +0200

> as requiring use of integ_req_flag in order to get integrity protection?

Yes, perhaps.

> 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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 30 Aug 2006 22:37:36 +0200

> 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: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 11:48:21 -0700 (PDT)

I don't know.  Do you?

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 15:04:50 -0500

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
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 15:54:16 -0500

> 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: Sam Hartman <[email-masked]>
Date: Wed, 30 Aug 2006 18:51:56 -0400

>>>>> "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.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 18:26:22 -0500

> 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
--

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Aug 2006 16:29:00 -0700 (Pacific Daylight Time)

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

-- Mark --

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 Aug 2006 11:53:45 -0400

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

I concur.