Subject: [Fwd: Re: Submission of draft-ietf-cat-iakerb-08.txt to IESG]

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 14 Oct 2002 16:16:59 -0500

As chairman of the krb-wg, I would like to submit this response to the IESG
to the complaint of [email-masked] from Fri, 21 Sep 2001 19:02:38 +0200 (METDST)
and the draft-ietf-cat-iakerb-09.txt should move forward. 

Since the submission of draft-ietf-cat-iakerb-08.txt, 
draft-ietf-cat-iakerb-09.txt has been submitted. Only one phone number and the 
expiration dates have changed. 

Jonathan Trostle, as one of the co-authors had sent the attached response to 
Martin Rex. I have not heard back from Martin and Jonathan has since changed 
jobs. This e-mail should stand as the WG response.

I believe Jonathan has refuted each of Martin's objections which I believe 
where based on a misunderstanding of how GSSAPI related IAKERB.  

-------- Original Message --------
Subject: Re: Submission of draft-ietf-cat-iakerb-08.txt to IESG
Date: Mon, 24 Sep 2001 17:05:13 -0700
From: Jonathan Trostle <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked],[email-masked],
[email-masked], [email-masked]
References: <[email-masked]>

Doug has asked me to respond to Martin's email; my response is inline:

At 07:02 PM 9/21/01 +0200, Martin Rex wrote:
>Douglas, Jeff, Marcus,
>
>I'm very strongly opposed that the document
>"draft-ietf-cat-iakerb-08.txt" is put on the standards track.
>I have been complaining about some obvious problems with this
>document during WG last call, but no one in the discussion
>seemed to have enought GSS-API expertise to understand why
>this spec is such a bad things.

I was hoping that you would enlighten me during WG last call, but that
didn't happen. As best I understand, the gist of your complaints seems to
be that SPNEGO and multiple OID's should be avoided. I don't see how a
secure negotiation can happen here without SPNEGO. If an IAKERB initiator
sends a IAKERB context token, and the responder doesn't support IAKERB,
there isn't any possible means to deal with this in Kerberos today, since
there is no shared key between the IAKERB initiator and the responder. So
there is no way to do secure negotiation without SPNEGO, in the common case
where the initiator doesn't know which mechanisms the peer supports.

>
>My suggestion is that all references to GSS-API are replaced with
>"Microsofts Security Service Provider Interface (SSPI)" and that
>the document is considered for "Informational" since there apparently
>is an implementation of it in Win2K.

How is that apparent?

>
>Besides being *seriously* underspecified, the proposal is incompatible
>with the GSS-API architecture in several places and can not be used
>by "portable applications" as it stands.  Considering this document

Please explain.

>would seriously ruin he overall quality of GSS-API.  The document
>might be just sufficient to allow on-the-wire interoperability,
>but it does *not* address the API side of the GSS-API at all.

It is a protocol spec, as is RFC 1964. But we would like to have existing
properly coded GSS apps be able to run over IAKERB without changes to the
application code. In other words, if this breaks GSSAPI, we would like to
know about it.

>
>I have only very limited knowledge about the Kerberos protocol
>internals, so I didn't read and comment on the Kerberos-related
>operations and data inside the protocol and token exchanges.
>Anyway, having read and though about some of the Kerberos protocol
>details of IAKERB some days ago I do have the feeling that
>engeneering-wise the protocol could be *much* better/cleaner.
>Unfortunately I have not seen any comments of the Kerberos-gurus
>on the IAKERB protocol details (neither good nor bad)...
>
>
>I have gained very deep and thorough familiarity with GSS-API 
>from application and mechanism point of view over the last 6 years,
>across more than a dozen different types and implementations of
>gssapi mechanisms which the customers of my employer's software
>can plug-and-play into our application.
>
>With permission of my employer I have released GSS-API v2 compliant
>code wrappers for Microsoft's NTLM and W2K Kerberos SSPs that
>are available for download from ftp://ftp.sap.com/pub/ietf-work/gssapi/
>While writing that code I noticed the defects in the SSPI spec
>(SSPI was derived from GSS-API), several serious implementation
>bugs and design flaws in the actual SSPs shipped by Microsoft
>and a serious architectural GSS-API incompabibility concerning
>host-based service names in W2K Kerberos.

Doesn't seem to be relevant to IAKERB.

>
>
>
>Obvious deficiencies of the IAKERB document:
>
>- the document talks of a negotiation but doesn't say how it is
>  to be done.   My position during WG last call was that when
>  using/requiring distinct mechanism OIDs for the two variant
>
>  (a) it would amount to an implicit requirement of SPNEGO,
>      which is bad because SPNEGO is optional for GSS-API,
>      a quite complex spec to implement (not just because of
>      the heavy ASN.1 stuffing) and would require additional
>      information on:
>        - how the application would have to setup/configure
>          the mechanism order

the application could use the default mechanism. SPNEGO is not required -
some initiators may know apriori which mechanisms the responder supports.

>        - describe where and how which mechanism OIDs will
>          be accepted/needed or emitted by the gssapi mechanism
>          so that the application sees a compliant gssapi mechanism

the call to init_sec_context that returns a complete status returns the
mech OID in use with the responder per RFC 2743.

>        - describe which mechanism OIDs will have to be tagged
>          on which rfc-1964 context-level and message-protection tokens
>          in order to allow on-the-wire interoperability of
>          the full communication (the spec currently only mentions
>          the new context-level tokens.

The spec. should indicate that all tokens are tagged with the new OID's.

>
>  (b) would not work for several types of existing portable applications
>      because these will suddenly see new mechanism OIDs for something

Shouldn't portable GSS apps be able to deal with new OID's without breaking?

>      that is essentially plain Kerberos 5.

There are new protocol elements. So it isn't plain Kerberos 5.

>      - portable applications that are capable to deal with multiple
>        independent gssapi mechanims without SPNEGO will probably
>        recognize and use the rfc-1964 Kerberos mechanism OID which
>        means that they cannot get benefit from IAKERB-enhanced
>        gssapi mechanisms at all.
>
>        I suggested to have the handshake among IAKERB/rfc-1964 completely
>        inside a modified rfc-1964 mechanism with the original single
>        mechanism OID so that all application would automatically benefit.
>        (active) IAKERB Author(s) disagreed.

You are asking for IAKERB to be integrated with the RFC 1964 mechanism. The
problem with the approach you suggest, as described above, is that some
responders will not support IAKERB. So if the initiator starts out with RFC
1964 and then decides to use IAKERB (perhaps the KDC cannot be reached),
the responder that doesn't support IAKERB will at best send an
unauthenticated error message to the initiator. So an attacker can cause a
fallback to something less than IAKERB (e.g. NTLM) even if the responder
supports IAKERB. SPNEGO and multiple OID's solves this problem.

In other words, the current approach in the draft offers more security than
the approach you are proposing.

>
>
>- There is an unsolved problem with Microsoft's idea of KDC-based
>  realm resolution and name-canonicalization with respect to the
>  GSS-API v2 model of binary ACLs that can be populated via
>  gss_import_name()+gss_canonicalize_name(mech_oid)+gss_export_name()
>
>  I think there might be a similar problem also with IAKERB, where
>  the proxy or KDC selects Realms or with the reversed context
>  establishment back to the client so that the IAKERB client might not
>  be able to verify mutual authentication or populate ACLs with
>  arbitrary names.  In distriuted applications it is often essential
>  that all names which are being used are fully usable and non-ambiguous
>  for all participating communication peers.

There is a general GSSAPI problem with names here. I don't see how IAKERB
makes this problem worse.

>
>  The problem with (a) names being not gss_canonicalize()able when
>  KDC-based name canonicalization is only available during actualy ticket
>  acquisition and the un(der)specified effect on TGS caching
>  was the reason why name canonicalization was (fortunately)
>  removed from the Kerberos revisions document.
>
>  A service directory for canonicalizing names is probably a good idea,
>  but it should definitely be implemented as a seperate service with
>  a seperate protocol exchange.  And it should return not only the
>  canonical name of a service instance, but also the network connection
>  information how that service can be reached.  Abstract service names
>  (without inherent hostname) are much more useful in distributed
>  environments, and much more common with authentication protocols
>  that permit sharing of acceptor credentials across all instances
>  of the same service.
>
>  Implementing an optional gssapi extension over such a name service
>  it easy and straightforward and would fit just fine into the
>  GSS-API model.  The tricks that some people play with their
>  Kerberos-native applications that they set up a DNS CName to
>  resolve round-robin to a particular host of a distributed service
>  so that the Kerberos client can pick the connection information
>  from the "canonicalized" hostname do not work at the GSS-API
>  level, because GSS-API is without transport!  Portable applications
>  will already have opened the network connection when they
>  call gss_init_sec_context(), and canonicalization of such
>  a name through gss_canonicalize_name() for ACL population
>  will not work either. 

Not relevant to IAKERB.

>
>
>
>The IAKERB document doesn't deal with any of the API issues of GSS-API
>(which is why the authors didn't realized that the proposal does not
>fit into the GSS-API architecture), therefore it should *NOT* be
>put on the standards track in the GSS-API family of documents.
>We do have SPKM (rfc2025) and LIPKEY documents with severe defects
>already, but IAKERB is really a nightmare for GSS-API.

RFC 1964 doesn't deal with API issues either. If there is a problem with
IAKERB and the GSSAPI architecture, please explain. I don't think it makes
sense to throw out SPNEGO and multiple OID's just because adding a new OID
breaks one application.

Jonathan

>
>-Martin
>
>
>
>Douglas E. Engert wrote:
>> 
>> The Kerberos Working Group of the Security Area would like to submit:
>> 
>>    "Initial and Pass Through Authentication Using Kerberos V5 and the 
>GSS-API"
>>     http://www.ietf.org/internet-drafts/draft-ietf-cat-iakerb-08.txt
>> 
>> to the IESG as a proposed standard. 
>> 
>> The draft-ietf-cat-iakerb-07.txt has under gone a recent WG last call, 
>7/2-7/18 which
>> was extended to 7/23. There where three minor points which need to be 
>clarified, and 
>> this was done for the final draft. The list of these and the response are 
>attached. 
>> The chair deemed that these changes where as requested during the last 
>call, and the
>> draft could proceed. 
>> 
>> I must report that a few days after the close of the last call there a 
>flurry of e-mail
>> where one individual wished to proposed a better solution. The chair 
>suggested that 
>> they could submit this as a new draft but that this draft has been under 
>development 
>> for several years, and it would proceed. 
>> 
>> 
>> -------- Original Message --------
>> Subject: Re: Working Group Last call - draft-ietf-cat-iakerb-07.txt
>> Date: Tue, 24 Jul 2001 15:49:00 -0500
>> From: "Douglas E. Engert" <[email-masked]>
>> To: [email-masked], Jonathan Trostle <[email-masked]>
>> References:
>> 
><[email-masked]><[email-masked]><3B49D01C.FCDBFD9@anl.
>gov><[email-masked]><[email-masked]>
>> <4.1.20010718155535.00d25e70@mira-sjc5-1> <[email-masked]>
>> 
>> The WG last call for the draft-ietf-cat-iakerb-07.txt has now ended. It had
>> been extended from 7/18 to 7/23 in order to get a few more comments
addressed
>> which came in on the last day. 
>> 
>> There where three comments, and let me try and summarize them:
>> 
>>  (1) An IAKERB server which also used the krb-dns-locate facility
>>      could allow an attacker to change DNS, and use the IAKERB server
>>      to attack other machines.
>> 
>>  (2) The draft should say it will used DER.
>> 
>>  (3) The draft may lead one to imply the SPNEGO was required since it
>>      defined multiple mechanisms, and this could lead to other problems
>>      as well. 
>> 
>> I believe the additional comments over the weekend did not show that there
>> was a problem in the mechanism OIDs, or the that SPNEGO would be required. 
>> 
>> 
>> Jonathan had said he would address (1) and (2) with additional comments in 
>the 
>> document.  Therefore the chair see that there is general consensus that
this 
>> draft should proceed. 
>> 
>> When Jonathan submits a new draft with these minor changes, I will advance 
>the 
>> draft. 
>> 
>> -- 
>> 
>>  Douglas E. Engert  <[email-masked]>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439 
>>  (630) 252-5444
>> 
>> 
>> 
>> -------- Original Message --------
>> Subject: draft-ietf-cat-iakerb-08.txt
>> Date: Mon, 17 Sep 2001 13:13:53 -0700
>> From: Jonathan Trostle <[email-masked]>
>> To: [email-masked]
>> CC: [email-masked], [email-masked]
>> 
>> Doug,
>> 
>> I have made the requested changes (from WG last call) to iakerb07 and
>> iakerb08 is now in the repository. Here are the list of changes:
>> 
>> (1) An IAKERB server which also used the krb-dns-locate facility
>>      could allow an attacker to change DNS, and use the IAKERB server
>>      to attack other machines.
>> 
>> I have added a description of this issue and several possible
>> countermeasures on pp.11-12 in the security considerations section of the
>> draft. 
>> 
>> (2) The draft should say it will use DER.
>> 
>> I added that the KRB_TKT_PUSH message is encoded using ASN.1 DER
>> in the bottom of p. 8.
>> 
>> (3) The draft may lead one to imply the SPNEGO was required since it
>>      defined multiple mechanisms, and this could lead to other problems
>>      as well. 
>> 
>> P. 4 Section 5, addresses this issue.
>> 
>> Additional clarifying text was added in a few places: P. 9 a new figure is
>> added to illustrate the minimal messages AS case, pp. 10-11 new step by
>> step text for both client and server for the minimal messages TGS protocol. 
>> 
>> The draft is now ready to be forwarded to the IESG per your decision at the
>> end of WG last call.
>> 
>> Jonathan
>> 
>> 
>> -- 
>> 
>>  Douglas E. Engert  <[email-masked]>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439 
>>  (630) 252-5444
>> 
>

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Oct 2002 22:10:45 +0200 (MET DST)

> where based on a misunderstanding of how GSSAPI related IAKERB.  

I'm sorry, but this is wrong.

The issue that requiring SPNEGO with no added value was simply denied 
without a remotely reasonable explanation.

Requiring each and every Kerberos vendor to implement such a
complex protocol like SPNEGO for zero benefit is an obviously
bad idea.

And even if someone can kludge up a weak explanation, the current
IAKERB spec is heavily underspecified for a GSS-API mechanism
so that creating two independent interoperating IAKERB from
that spec is definitely impossible.  In our Email discussion
on ietf-krb I gave several examples where and why it is
incomplete.

The current IAKERB internet draft is at most EXPERIMENTAL quality,
but in my opinion it is acutally a broken and wrong approach and
by putting this document on the standards track we may cause
considerable damage and confusion among implementors.

Jonathan clarified ONLY that IAKERB was using user2user authentication
and not reversing the authentication.  That was only a secondary
question that I had and for which I clearly indicated that I didn't
have enough knowledge about the Kerberos protocols to determine
what was going on internally.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 16 Oct 2002 16:28:15 -0500

In response to Martin's most recent complaint, I am send this response 
Jonathan Trostle sent to me early this morning before the note from Martin. 
As the krb-wg chair, the way I see it, Martin is the only one with complaining,
and that draft should move forward.

Jonathan Trostle wrote:
> 
> Hi Doug,
> 
> I have enclosed a note for the IESG on IAKERB. Please let me know if you
> need anything else to turn IAKERB into a RFC:
> 
> Dear IESG,
> 
> The Kerberos WG chair, Doug Engert, has asked me to send a note to you
> responding to some comments by Martin Rex during the IETF last call for 
> the Internet draft draft-ietf-cat-iakerb-09.txt. This draft has previously 
> passed the Kerberos WG last call. 
> 
> Martin had a concern regarding the use of user passwords as encryption
> keys in the IAKERB minimal messages protocol. I responded to his concern 
> at the time and explained that user-user authentication is used, so that
> we have not created any new protocol usage of password derived keys (there
> is the existing possible use of password derived keys in the AS exchange of
> the Kerberos protocol). This fact is also clearly documented in the draft.
> As Martin indicated in one of his emails, his expertise is not in the area 
> of the Kerberos protocol, rather, he has experience with GSSAPI 
> implementation.
> 
> Martin also has a concern regarding the possible use of SPNEGO (RFC 2478) 
> in conjunction with the IAKERB protocol. In particular, SPNEGO can be 
> used to securely negotiate between Kerberos, IAKERB, and other existing 
> GSSAPI mechanism protocols. Allowing SPNEGO to be used here gives a 
> security advantage. Without secure negotiation, there is no way to prevent 
> a downgrade attack to a less secure protocol in a realistic deployment 
> where some hosts support IAKERB and some don't. In particular, the IAKERB 
> 
> initiator and responder do not initially share a secret key and so cannot 
> create any authenticated error messages. Withoutesome additional secure 
> 
> negotiation protocol such as SPNEGO, there is no way to prevent a 
> downgrade attack to a lesser authentication protocol. 
> 
> Jonathan 

--

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Oct 2002 00:06:05 +0200 (MET DST)

> and that draft should move forward.

The reason why no one else is complaining is quite simple.

There is not a single implementor for this stuff, not even the
authors have tried to implement it from what they said in the past.

And then there are very few people intimate with GSS-API on this
list, and the only aspects of IAKERB on which I am complaining badly
is the GSS-API side of the spec.

This forum seems totally inadequate to discuss the gssapi side
of the IAKERB spec.  Since the cat-ietf forum has dissolved over
the past few years and even been officially concluded a short
while ago, the IAKERB spec should not be considered the product
of a working group.

As I have been saying all the time:
- the underlying issue that IAKERB tries to address are valid and real
- I personally don't have enough Kerberos expertise to comment on
  the Kerberos protocol issues and Kerberos design aspects of IAKERB,
  and this part might be quite ok as it is.
- What I'm quite competent for is GSS-API architecture, because I've
  been doing just that for the last 8 years almost daily, having
  been exposed to more than 20 independent gssapi implementations from
  various vendors all around the world, and the minority was Kerberos 5
  mechanisms.  The IAKERB embedding into GSS-API is (a) a complete
  mess breaking with the GSS-API architecture in several ways and
  (b) totally underspecified for being an actual gssapi mechanism spec.

When looking at the devastating results from independent implementations
of rfc-2025 (I've seen about 10): no two of them are fully interoperable,
and I had to educate every single vendor about the defects in rfc-2025
and what to do instead to come up with an implementation that our
customers will actually find useful.

And still rfc-2025 is magnitudes better for a mechanism spec than IAKERB...

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Oct 2002 00:49:51 +0200 (MET DST)

Douglas E. Engert wrote:
> > in conjunction with the IAKERB protocol.

My concern wasn't against permitting SPNEGO,
it was against *requiring* SPNEGO for zero benefit for every
Kerberos implementor that wants to add IAKERB.

SPNEGO is a awfully complex protocol, mostly because it uses
ASN.1 all over the place -- something which definitely makes
SPNEGO extremely unattractive for most implementors.

> > In particular, SPNEGO can be 

This tells me that Jonathan still doesn't understand SPNEGO.
I've tried before to tell him that SPNEGO doesn't have any single
bit of crypto by itself, so it is completely impossible for SPNEGO
to securely transfer a Kerberos error message.

(a) SPNEGO needs a successful security context establishment of a
common gssapi mechanism between initiator and acceptor and (b)
this common mechanism must support message integrity protection.
Only then can SPNEGO use this message protection facilities to
sign the originally exchanged context tokens and transfer this
signature to the peer in order to verify that the SPNEGO handshake
was not modified.  In case of an error during context establishment
or when the server doesn't support SPNEGO at all there is a simple
failure that cannot be distinguished from a DoS or downgrade attack.

There are other aspects of SPNEGO (and Kerberos) which Jonathan is
completely ignoring.

- current IAKERB requires meta-knowledge for the application in order
  to conciously request and configure it for an SPNEGO handshake.
  Keep in mind that GSS-API is without transport, so the only clue
  (at the generic level) that SPNEGO has about the target is the
  name that the application supplies as target_name to the initial
  call of gss_init_sec_context().  There are no clues/hints whatsoever
  in the spec who decides if IAKERB is used.  It's also not documented
  how the application could configure IAKERB (in case it would),
  so I really doubt this would work with a "portable" gssapi-based
  application (that doesn't have meta-knowledge to trigger IAKERB use
  via non-standard API calls), and not by a generic SPNEGO which also
  doesn't have meta-knowledge about the IAKERB stuff. 

- SPNEGO requires a common namespace for the mechanisms for which
  it handshakes.  A common namespace for the acceptor/server if you want
  mutual authentication, because you need to supply the target
  name upfront to the initial call to gss_init_sec_context() --
  reminding you that traditional rfc1964 Kerberos requires the target
  name even for target-only authentication -- and that not using a
  target name will make an (unspecified!) non-standard control api
  for configuring/driving SPNEGO under IAKERB unavoidable.
  A common namespace for the initiator(s)/client(s) is necessary so that
  the server will be able to serve the client independent from the gssapi
  mechanism that was actually used to authenticate the client. 

- What will you recommend applications to do if the peer doesn't implement
  SPNEGO at all?  This will definitely lead to a fatal error on the
  acceptor/server side from gss_accept_sec_context() and it is not unlikely
  that server has a non-sophisticated error handling that will cause
  the silent termination of the network connection only.

  Be aware that this will be a very common situation for quite some time
  since there are very few SPNEGOs out there, and even fewer applications
  that use it.
 
  If the recommendation is to retry with a non-SPNEGO gssapi handshake
  (e.g. a fail-over mode), then you loose all your SPNEGO protection.
  But the alternative would be to loose all connectivity to these hosts ...

- For many situations where you have a meta-knowledge that the other side
  will understand IAKERB under SPNEGO, you could just use the meta-knowledge
  to use IAKERB inside Kerberos with the exact same security characteristics
  (because SPNEGO would only use Kerberos to provide its services anyway)

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 16 Oct 2002 23:17:30 -0400

>[...]

Alright, I think I've got to chime in here (not as a document author,
but as a disinterested third party).

I read Martin's issues.  Since I'm not nearly the GSS-API expert
that he is, I can't provide good comments on the GSS-API architechture
issues ... but the more that I think about it, the more I have to
wonder if doing IAKERB makes sense _in the context of GSS-API_.
I mean, does GSS-API _really_ add any value here?  It seems to be
solely used as a transport mechanism, and I personally think it's
not the best choice as a transport mechanism.  If the goal is to maybe
use IAKERB, but also maybe use another of GSS-API mechanism, I could
see where it would make sense ... but I am having a hard time coming up
with a case where you would want to do IAKERB and _another_ GSSAPI
mechanism to the same service.

If the goal is to get SPNEGO, well, shoot ... I think that's adding a
bunch of baggage that you don't need ... take the features you need from
SPNEGO and put them in the protocol directly (since I'm not sure you could
even use an off-the-shelf SPNEGO implementation with this).

If the goal is to use a standardized API, I think you're going to have
to provide some IAKERB-specific extension to actually _use_ the dang
thing, so any value you get from GSS-API goes out the window.

Just my $0.02.

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 17 Oct 2002 02:56:58 -0400

> is the GSS-API side of the spec.

And this is exactly why I'm inclined to defer to Martin's expertise.
Not that I necessarily think he's right, and I've disagreed with him
at times in the past (though I attribute much of that to mutual lack
of experience -- him with Kerberos and me with GSSAPI) but if he
thinks there are serious problems, I'd oppose moving it forward until
Martin's objections are addressed to his satisfaction, or at least to
mine :-).

> of the IAKERB spec.

Yes, it does.  So what would a more appropriate forum be?

> customers will actually find useful.

So, Martin, have you talked to Adams about writing rfc2025bis, or at
least an update to rfc2025?

Ken

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Oct 2002 13:53:58 +0200 (MET DST)

> Yes, it does.  So what would a more appropriate forum be?

I have the feeling there isn't any (anymore) within the IETF.

Maybe you've heard that normally the IETF doesn't do APIs and
GSS-API from the CAT working group was an exception (in many
ways, including the time it took to complete the spec...).

CAT was quite a remarkable forum.  It did have quite some very
experience engineers with a significant diversity and it was
extremely successful in recognizing and distinguishing vendor
pressure and political lobbying from technical issues in the
discussions, at least for the base GSS-API spec.

Things like SPKM and SPNEGO didn't receive any deep scrutiny
however, mostly because the specs were full of ASN.1 and
there were few (if any) real implementors of these specs
involved in the discussion.

> least an update to rfc2025?

Yes, I tried to persuade im on several occasions to work on a
successor document, via Email and on IETF meetings like the
one in L.A. spring 1998, but I was unsuccessful.

SPKM is basically the description of an Entrust product at that time.
When Entrust came to us to have this product certified for interoperability
with our application all of the problems of the SPKM spec surfaced and
they had to fix their product in several ways to get certified.

However that didn't seem to affect Carlisle's position in any way --
he was *not* the engineer who had to fix the problems of his spec.

Since I was ASN.1 illiterate at that time I hadn't even read the spec
before it was published.  And I'm still an ASN.1 novice and not
skilled enough to architect or revise a spec full of ASN.1.
I'm also far from being an X.509 expert, although I've been working
on and maintaining an OEM SSL implementation for the last 3 years
that we provide for our application.

Last time that I complained about rfc2025 was when Mike Eisler
proposed LIPKEY based on rfc2025, which I said he shouldn't do
before having fixed the problems of rfc2025...  

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 17 Oct 2002 10:35:43 -0500

Lets look at RFC 2026:

 4.1.1  Proposed Standard

   The entry-level maturity for the standards track is "Proposed
   Standard".  A specific action by the IESG is required to move a
   specification onto the standards track at the "Proposed Standard"
   level.

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

Many of the arguments I have head over the last few days are:

 o There might be a better way to do this.

 o No one has implemented it yet. (If anyone has, please speak up!)

 o The use of SPNEGO adds extra baggage. 

We have a catch-22 here. Those interested in it are waiting for the draft
to be a Proposed Standard before implementing. They appear to believe it is
well-understood, as they are pushing for it to be a Proposed Standard. It has
been in the CAT and now KRB-WG for a long time, and before the IESG now for a 
year! We might not get any better understanding till it is implemented. 
    
If "further experience" dictates this might result in a change or retraction. 
If there are others who feel that there is a better way, with or without
GSSAPI or SPNEGO, they could propose an alternative. But would there be enough
"community interest to be considered valuable" for this alternative.

It has stalled for a year. so I say it is time to get moving forward, so 
implementations can be tried.      

--

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Thu, 17 Oct 2002 11:45:19 -0400

<[email-masked]>
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigADAB4BDE74BF5F8A62CF7767
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The way forward may well be for someone to implement the current ID, to 
refute the arguments that it cannot be implemented.

			-Jeff

> implementations can be tried.      

--------------enigADAB4BDE74BF5F8A62CF7767
Content-Type: application/pgp-signature

--------------enigADAB4BDE74BF5F8A62CF7767--

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Thu, 17 Oct 2002 11:25:12 -0400

I will perform a detailed reading of the document and all of the 
comments and let you know how I will proceed. IETF process does permit 
"rough" consensus, which is to say that there can be dissenters.

			-Jeff

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Oct 2002 20:40:05 +0200 (MET DST)

Hi Jeff,

> refute the arguments that it cannot be implemented.

I did *not* claim that it could not be implemented.

Although I would expect a resonable implementor to complain loudly,
I've seen to many engineers (e.g. gssapi implementors) to read RFCs
as gospels, even where they're obviously wrong.  I know that with
discussions from *each* and *every* vendor's engineer(s) that had their
gssapi implementation certified for interoperability with our application.

Repeating myself:

- SPNEGO is an awfully large but completely unecessary burden

- the way it is written it breaks the GSS-API architecture
  (i.e. the abstraction) in several ways, first of all by handing
  configuration/negotiation off to SPNEGO or the application or both
  while at the same time being totally silent as to how to get at
  the necessary meta-knowledge and what kind of unspecified API
  extensions to the underlying Kerberos are necessary to make it happen.

In addition to that, I don't think that IAKERB requires any kind of
negotiation at all.  Either the local Kerberos doesn't have necessary
credentials/tickets and will need it (badly), or it does have all necessary
tickets or necessary network access and then the default should be
not to use IAKERB.  (Providing a propriatary Kerberos extension to
force one or the other would be ok but need not necessarily standardized
in *this* case -- GSS-API related protocol specs should first of all
address the requirements for "portable" applications that do not
use any proprietary extensions.

Hiding the IAKERB magic totally inside the Kerberos implementation will
provide the least burden for the implementors, the maximum compatibility
with existing gssapi based applications and the best interoperability
with installed base of plain rfc-1964 Kerberos implementations.

PLEASE don't count on engineers from aggressive vendors to fix
problems in protocols that were published as (standards track) RFCs
in the IETF because this will hardly happen (it happens only when
the developers get personally involved and follow through on
their own).  It is much more common in the Open Source community
to get personally involved and get involved in the IETF standards
process...

Look at what companies are doing with the so-called
Web Technology, like my employer.  Our engineers here have a really
hard time to make their large and stateful applications work with
Frontends based on off-the-shelf Web-Browsers.
I told them years ago that if they want to use standardized technology
but have a problem with it they should go and participate the
standardisation and fix the protocols so that Browsers will become
remotely useful as generic application front-ends in a few years.
Well, they still don't participate, mostly because they want
to ship in a matter of month not years -- and they don't plan
ahead this far.  Even our board, once visionary has cut down
to planning ahead only a couple of months with their requirements
and projects for us (while still requiring us to project our
budgets 1.5 years ahead ...).  And our other engineers just keep
bragging about the lack of features in the protocol and the
hoops they have to jump to make things work *somehow*.
Effectively they're building and shipping applications that lack
design&architecture, and worst of all: they lack robustness.

> > been in the CAT and now KRB-WG for a long time, and before the IESG now for
> > a year! We might not get any better understanding till it is implemented. 

This has the smell of the OSI Protocols and the CORBA-1.0 approach:
Design by committee -- reality checks and prototypes are for weenies.

> > GSSAPI or SPNEGO, they could propose an alternative. But would there be
> > enough "community interest to be considered valuable" for this alternative.
> > 

In its current state I would not like to see this spec published as
a Proposed Standard.  Personally I consider it even to underspecified
and to much contradiction to the existing GSS-API standard for
"Experimental".   As long as there is not even a single implementation
it might even be questionable for "Informational" ...

You know why SPNEGO and SPKM1 and are as bad as they are (and full of
ASN.1)?  Because noone else was able or willing to author a good
alternative proposal.

It similar with the "Kerberos Change password" and IAKERB.  Curiously
the Kerberos Change password has a funny mixture of ASN.1 and
concrete structures, simply because there was a predecessor proposal
by Marc Horowitz.

I mean, just look at the mess that Microsoft created with the
HTTP-authentication using a SPNEGO-wrapped Kerberos token exchange
in HTTP header fields.  It is about the worst conceivable abuse
of SPNEGO that one could entertain.  However since the implementation
of this mess is shipping with millions of copies of MSIE and IIS
it's ok that we have a document describing it as an Informational Draft.

Really, look at that document and think about it.  I couldn't believe
it when the document was initially submitted as an I-D and had a
few questions on it.  (I don't know whether the answers went into
the document for clarification.)

- it uses SPNEGO (MSIE will send it, so Web-Servers need to
  be prepared to deal with it if they want to interoperate).
- it *requires* the optimistic context token in the first token
  (which the SPNEGO spec declares as optional!!)
- the protocol exchange supports only a single round trip, i.e.
  a token with the HTTP-Request, the reply token with the HTTP-Reply,
  so actually it doesn't support negotiation at all -- if the
  optimistic token doesn't fit you loose.
- If you wanted to protect the contents of a HTTP Post, this would
  require GSS_C_FLAG_PROT_READY (=availability of message protection
  before the security context is fully established) which is somewhat
  incompatible with SPNEGO (since it contradicts negotiation).

Now the most confusing issue for me was that this handshake is supposed
to work with NTLM as well -- however NTLM uses a 3-way handshake
(because it is a challenge-response protocol) and I have not received
any response as to what hacks they're using.  Certainly IETF-SPNEGO
will *not* accept any tokens on the initial call to gss_init_sec_context()...

I have considered the idea of IAKERB valid and useful since Mike Swift
brought it up at the L.A. IETF in spring 1998, but I really dislike
the currently proposed embedding of it into the architecture of
GSS-API and the Kerbers gssapi mechanism.

For a standards body the "anything is better than nothing at all"
may result in standards with poor quality.  And what is significantly
worse than a broken standard?  A large installed base of a broken
standard -- it is *significantly* harder to overcome/fix.

So *I* am not looking forward to the result when vendors take
the lead in implementing flawed or questionable specs, often it
doesn't result in better specs but in more complex specs that
remain as flawed as they originally were enriched by hints
that enumerate what additional interoperability problems certain
vendors' implementations have.

There are so many things that I would like to do but I'm lacking
the time for most of them.  It's not about an hour here and there,
but about a commitment for a certain effort for a longer time,
which is certainly required to come up with something at a
standards quality level.

-Martin