Subject: Submission of draft-ietf-cat-iakerb-08.txt to IESG

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 20 Sep 2001 14:20:45 -0500

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]><[email-masked]><[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: Steve Coya <[email-masked]>
Date: Thu, 20 Sep 2001 17:12:52 -0400 (Eastern Daylight Time)

Douglas,

I'm writing to acknowledge receipt of your request. It will appear on the
Requests web page after being updated tonight. 

Note that this does not imply any action on the IESG's part; just that your
request has been received and will be posted. 

Steve

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Sep 2001 19:02:38 +0200 (METDST)

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.

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.

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

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.

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

  (b) would not work for several types of existing portable applications
      because these will suddenly see new mechanism OIDs for something
      that is essentially 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.

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

  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. 

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.

-Martin

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 21 Sep 2001 12:22:05 -0700 (PDT)

> is an implementation of it in Win2K.

This is not the case. Neither Windows 2000 nor Windows XP implement
IAKERB.

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 24 Sep 2001 17:05:13 -0700

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

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

>is an implementation of it in Win2K.

How is that apparent?

>by "portable applications" as it stands.  Considering this document

Please explain.

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

>host-based service names in W2K Kerberos.

Doesn't seem to be relevant to IAKERB.

>        - how the application would have to setup/configure

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

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

>          the new context-level tokens.

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

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

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

>  for all participating communication peers.

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

>  a name through gss_canonicalize_name() for ACL population

Not relevant to IAKERB.

>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

><[email-masked]><[email-masked]><3B49D01C.FCDBFD9@anl.
>gov><[email-masked]><[email-masked]>

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 Sep 2001 13:53:25 +0200 (METDST)

Jonathan Trostle wrote:
> didn't happen.

I did.  You were there, too -- I don't know why you believe that
you missed it.

>
> As best I understand, the gist of your complaints seems to
> secure negotiation can happen here without SPNEGO.

You still don't seem to understand where the protection in SPNEGO
comes from, although I did explain it in detail in above Email.

Of course you can get the EXACT SAME protection of the negotiation
that SPNEGO could possibly provide inside the Kerberos gssapi mechanism.
Reread SPNEGO please.

I've already explained this twice.  Go back to your personal
email archives or the ietf-krb archives and look up my Email:
  Date: Mon, 23 Jul 2001 17:58:13 +0200 (METDST).
  Subject: Re: Working Group Last call - draft-ietf-cat-iakerb-07.txt
  Message-Id: <[email-masked]>

> If an IAKERB initiator

The initial document was presented at the LA IETF by Mike Swift
(at that time still working for Microsoft on W2K Kerberos), there
have been comments from Microsoft guys on ietf mailing lists
and Microsoft is the only company that I know that actually
has an implementation of SPNEGO (that is why they don't care about
the added complexity by requiring SPNEGO).

I don't know whether Microsoft has shipped it already, but
I'm pretty sure they do have code and do want to ship.
It wouldn't be the first time that Microsoft added new functionality
in a service pack to one of theis OSes.

> >by "portable applications" as it stands.  Considering this document

If you can't realize the problems from examples listed in the original
Email, then you probably don't have the necessary GSS-API expertise.

GSS-API is an API.  And a standardized API means that you should
be able to plug and play "portable" gssapi based applications
and arbitrary gssapi mechanism without having to change code.
Adjusting the configuration (user supplied input to the API)
must be sufficient.
Rearead rfc2743/rfc2744 please.

Since the IAKERB document added two new mechanism OIDs, there
arises (1) the ambiguity where to return which OID (1a) at the
API level and where to put which in the (1b) gssapi token framing
of the underlying rfc-1964 gssapi mechanism.  This ambiguity
would have to be removed, but the exact behaviour must be
consistent for each individual gssapi mechanism, whether or
not beneath SPNEGO!  You can use my free gssapi mechanism test tool
to verify consistent mechanism behaviour:

ftp://ftp.sap.com/pub/ietf/gssapi/gsstest/

The other problem is non-explicit requirement of SPNEGO in the
IAKERB document.  You are fighting so much for SPNEGO that I
assume you would use it in your implementation.  Now if your
client (with SPNEGO) was initiating a connection to a server
that implemented IAKERB without SPNEGO, it would result in
GSS_S_BAD_MECH being returned on the server from gss_accept_sec_context().
-- this means that when you do not require SPNEGO, people will
be able to come up with compliant non-interoperable implementations.
Think about it.

In the IETF we shouldn't put such stupidity on the standards track.

> application code. In other words, if this breaks GSSAPI, we would like to

Rfc1964 is much more than a protocol spec.  It covers (most) of the
API-related issues that a gssapi mechanism spec needs to address
the area that IAKERB completely lacks.  On top of that, rfc1964
basically has just a single mechanism OID, that's why it doesn't
need to address ambiguity issues here.  There is a minor issue
with pre-rfc1964 mechanisms and backward compatibility that is
not covered by rfc1964 (for those that implement it)
MIT Kerberos initially had a few inconsistencies but these have been
fixed quite a while ago.  Rfc1964 is not perfect, but it's ok
and the best mechanism spec we on IETF standards track.
Reread rfc1964 please.

> some initiators may know apriori which mechanisms the responder supports.

This "liberty" would cause an obvious interoperability problem, see above.

> mech OID in use with the responder per RFC 2743.

There are more calls that deal with OIDs in GSS-API, and rfc-1964
puts a mechanism OID into the framing of ever context-level and
message protection token.
Reread rfc2743/rfc2744 and rfc1964 please.

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

Gosh, no-one would have though in that direction at all.
Now this precise spec removes all possible ambiguities ... doesn't it?

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

Yes, they do.  But mechanism-aware portable applications might be dealing
with a single mechanism OIDs per library, in which case they run either
completely without IAKERB (going straight for rfc1964) or they chose
a fixed suboptimal IAKERB variant because those applications aren't prepared
to select among the two IAKERB variants and rfc-1964 based on implementation-
defined characteristics that are not even available at the gssapi level.

> supports IAKERB. SPNEGO and multiple OID's solves this problem.

What you're saying sounds extremely like a requirement for SPNEGO to
avoid interoperability problems.  I really don't understand why you
and Douglas are fighting against this fact.

You might not be aware of it, but including NTLM is the worst possible
example for SPNEGO -- since NTLM in general lacks integrity protection,
and even requesting integrity or confidentiality protection on the initiator
side will cause the some acceptors to fail with a "FUNCTION_NOT_IMPLEMENTED"
error...
If you knew about all the bugs in all the various NTLM SSPs that Microsoft
shipped over the years you would know that NTLM as a mechanism is a PITA.

Anyway.

Even when you're hiding IAKERB totally within rfc-1964 Kerberos,
it will not prevent you from using SPNEGO on top to switch to
NTLM when that is available as a fallback.

Using distinct OIDs for IAKERB on the other hand requires everyone
to implement SPNEGO, which is quite a complex protocols,
and leaves several mech OID ambiguities unresolved.  All that
with no added value (well, ok, it does put Microsoft into an
competitive advantage since they already have SPNEGO, and
since the OpenSource crowds very slowly implement ASN.1-polluted
protocol specs like SPNEGO).

> the approach you are proposing.

You should know that this is BS.

> makes this problem worse.

That's *not* a GSS-API problem.
GSS-API is just fine and I can show you a lot of running code.
I can also show you code breaking on W2K Kerberos name canonicalization.

> sense to throw out SPNEGO and multiple OID's just because adding a new OID

When you talk about "throwing out SPNEGO" this almost sounds like you're
agreeing that there is an implicit requirement for SPNEGO...

I want the multiple mechanism OIDs plus implicit SPNEGO removed since it

- it adds serious complexity while adding zero value
  -- the negotiation can be implemented inside an rfc-1964 mechanism
     with the same characteristics 

- it causes interoperability problems with several gssapi-based
  applications that have been doing independent multimechanism long
  before SPNEGO

- it totally prevents interoperability with installed base of
  vanilla rfc-1964 mechanisms for situations where IAKERB is unnecessary

When will the Kerberos guru's start looking at the IAKERB internals?
One of the things that IAKERB proposes is to inverse the actual
context establishment between initiator and acceptor (i.e. Ticket
acquired by application and sent to User).  I don't know whether
all of the implications have been sufficiently addressed and
I'm not sure whether it is a good idea in the first place.

-Martin