Subject: Re: Working Group Last call - draft-ietf-cat-iakerb-07.txt

From: Martin Rex <[email-masked]>
Date: Thu, 19 Jul 2001 19:11:06 +0200 (METDST)

Ken Raeburn wrote:
> 
> "Douglas E. Engert" <[email-masked]> writes:
> > Does this really require SPNEGO, or just make it possible to use it?
> > Section 7. states SPNEGO [8] may be used to securely negotiate between 
> > the protocols. I don't see this requiring its use. It could be the client
> > and server must know in advance which mechanism to use, and don't try 
> > and negotiate.
> 
> I could be wrong, but I suspect it just encourages its use.  MIT's
> Kerberos ftp/ftpd won't talk to another GSSAPI ftp/ftpd that doesn't
> use the Kerberos mechanism; this seems like the same sort of deal.
> It's just that if you implement everything in this draft, you've got
> more than one mechanism, so you may need a way to choose or negotiate.
> If MIT's GSSAPI implementation had a second mechanism, we'd have
> exactly the same problem.
> 
> If the application protocol lets you try to initiate multiple times
> with different GSSAPI mechanisms, that's pretty much the same as an
> insecure negotiation, and should probably be discouraged, unless maybe
> the second mechanism is SPNEGO.  But if it's allowed, it is a form of
> negotiation....

It true that the spec doesn't say that it requires SPNEGO.  However
to make it work *somehow* the way the spec currently reads, that
would be an implicit requirement.

Thinking about it, the spec is probably flawed even under the
assumption that SPNEGO is available!

Currently, SPNEGO is the only gssapi mechanism that has the
exempt from having to behave consistently on its mechanism OID.
And this exemption is possible without breaking the GSS-API
abstraction, since none of the mechanism-specific tokens
have to be mutilated to perform a context establishment under
SPNEGO.

Since the iakerb spec is actually an extension to rfc1964, it should
really say so and re-use that mechanism OID and do the magic stuff
with the internal token tagging.  Otherwise each one of
"IAKERB minimal messages" and "IAKERB proxy" will have to
"mutilate" the rfc-1964-messages of the later communication by
replacing the Kerberos OID in front of these tokens with
either of the IAKERB gssapi mechanism.  Similarly, the mechanism OID
that must be visible to the application after context establishment
will have one of the IAKERB mechanisms.

If IAKERB would use the Kerberos mechanism OID it would at least
look Kerberos-compatible for all of the applications, and it would
allow the gssapi mechanism to use IAKERB when the application
asks for the Kerberos mechanism but the mechanism knows that plain
rfc-1964 will not work but IAKERB could be tried.  If no credentials
are available, the KDC cannot be reached and the acceptor/server
doesn't implement IAKERB then the gssapi context establishment
will always fail, independent of what OIDs are being used, so
inventing new OIDs does *NOT* add any value, however new OIDs
might require changes to existing applications -- which is bad.

-Martin

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 19 Jul 2001 11:45:07 -0700

>would be an implicit requirement.

Couldn't two peers have decided they will both use IAKERB proxy and just
use that? i.e., no negotiation.

>will have one of the IAKERB mechanisms.

I don't see why this is bad - why shouldn't the app be able to determine
that iakerb was used?

>might require changes to existing applications -- which is bad.

If adding a new mechanism underneath requires changes to the app, then it
would appear that the whole GSS paradigm is broken.

If the responder supports rfc1964 but not iakerb, how does it securely
indicate that to the initiator who has initiated with iakerb as the
preferred mechanism?

Jonathan

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Jul 2001 23:00:19 +0200 (METDST)

Jonathan Trostle wrote:
> I wrote:

In principal that's fine.

In the normal case it works different, though:

Either
 (1) the initiator requests the default gssapi mechanism (this is what
     most applications, in particular most *portable* applications are
     going to do,
or
 (2) in case there is more than one mechanism available to the initiator
     the initiator selects a particular gssapi mechanism which it
     thinks that the acceptor does in fact support.

Each of the two IAKERB mechanisms will more or less include a full-fledged
Kerberos 5 gssapi mechanism.  So it is to be expected that an implementation
that offers IAKERB functionality will also offer rfc1964 Kerberos.
Now which one is going to be the "default" mechanism?

For portable applications the mechanism implementation will probably
need to decide by itself whether to use IAKERB or straight rfc-1964
based on the availability of credentials and accessibility of a KDC.
And this information may dynamically change with the type of
the network connection that is used.

In case (2), although the application will have an obvious method
to select among the 2 IAKERB and straight rfc-1964,  the spec
completely lacks the precise spec (and API) how the application should
determine which one to use.  Although it might be nice if the
application can influence the selection, forcing each and every
application that tries to distinguish gssapi mechanism to learn
the nifty details about how to figure out which of IAKERB/rfc1964
to use is plain stupid.

The idea to use seperate gssapi mechanism OIDs for IAKERB is evil.

> I don't see why this is bad - why shouldn't the app be able to determine

It's fine to let those apps that care (the minority) distinguish which
variant of Kerberos (IAKERB1/2 or rfc-1964) was used.
Distinguishing them by mech-oid is one, but it is *NOT* the only
possible way.  Acutally it is the worst possible way.
Another possibility would be to return a mechanism-specific
context flags from gss_init_sec_context()/gss_accept_sec_context().
Cybersafe Kerberos uses these flags to indicate product-specific
features.  I think we could allocate/reserve mechanism specific
status bits (following the currently existing generic flags --
vendor specific flags draw from the other end of the bit-space,
at least for the C-Bindings).

> would appear that the whole GSS paradigm is broken.

GSS-API is fine.

If an extension to the Kerberos mechanism requires changes
to applications so that they request IAKERB whenever it is needed,
that would indeed be bad.

> indicate that to the initiator who has initiated with iakerb as the

I pointed this out before: GSS-API has neither negotiation nor "failback"
(i.e. fallback after an error).

What you request is only possible with an updated responder.
If IAKERB would reuse the rfc1964 OID then only an updated responder
(one that implemented IAKERB) would be necessary.

With the use of distinct OIDs, both ends would need need to be updated
with IAKERB *and* SPNEGO, and the initiator would additionally need
the meta-knowledge that the responder did not only have IAKERB, but
SPNEGO as well.

We would be significantly better off with doing the IAKERB
negotiation inside Kerberos tokens!

-Martin

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 19 Jul 2001 17:13:25 -0700

>Now which one is going to be the "default" mechanism?

That's a local policy decision. You could make rfc1964 the default and
fallback to iakerb on certain errors (such as when the KDC can't be reached).

>the nifty details about how to figure out which of IAKERB/rfc1964

As you say, most apps will use the default. But this is implementation
specific, and doesn't affect the protocol.

>that would indeed be bad.

I agree with you here. But most apps should just request the default
mechanism so they won't have this problem. If the default fails, then
another mechanism (such as IAKERB) can be tried.

>(one that implemented IAKERB) would be necessary.

The majority of responders won't be updated. SPNEGO solves this problem of
securely negotiate among multiple mechanisms, using the OID's of the
various mechanisms.

Jonathan

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2001 19:37:54 +0200 (METDST)

> fallback to iakerb on certain errors (such as when the KDC can't be reached).

Piloting error.
IAKERB is not a policy issue, it is a Kerberos extension to
overcome a lack of direct IP connectivity to the KDC.

I haven't verified, but I don't think that IAKERB weakens
the Kerberos authentication.  (It does open the application server
to a few additional DoS scenarious, though).
Since it's basically still Kerberos, it doesn't add to security
either.  Therefore this is not the place for a "policy" decision.

However, as IAKERB puts more workload on the application server,
the client should prefer straight rfc1964 whenever that is possible.

> specific, and doesn't affect the protocol.

For application that request the "default" mechanism is is completely
unnecessary to use seperate mechanism OIDs for IAKERB.

For most applications that request a gssapi mechanism by OID it
will be an clear and serious problem if IAKERB does not reuse
the Kerberos mechanism OID!  It will require significant and
complex changes to each application to accomodate such a fallacy.

Scenarios:
   - an existing application that runs on top of multiple independent
     GSS-API mechanisms today (no SPNEGO) and keeps track
     (e.g. by tagging the target name) which mechanism needs
     to be used for which target.  Now in order to benefit from
     IAKERB extension to Kerberos, the application will have to
     be changed significantly, because it will have to figure
     out in which situation to request which of the mechanisms
     (depending on the current network connectivity -- think of
      laptops, portables, dialup from home, etc.)

   - an existing application that runs on top of multiple independent
     GSS-API mechanisms today and *uses* SPNEGO and keeps track
     (e.g. by tagging the target name) which mechanism needs
     to be used for which target will need to be changed
     significantly in order to learn how to layout the list of
     Kerberos mechanisms in the SPNEGO list, depending on the
     current network connectivity.

It should be obvious that using distinct mechanism OIDs for the IAKERB
Kerberos extension will not add any value but cause significant problems
to applications.

Besides trying to deny that these problems don't exist, is there
any real *benefit* from distinct mechanism OIDs (which can *not* be
gained in a more backward-compatible fashion)?

> another mechanism (such as IAKERB) can be tried.

apps requesting the default mechanism will be just as happy with
IAKERB reusing the Kerberos mechanism OID.  At the same time
this will significantly reduce the complexity of IAKERB and the
impact on the existing protocol and existing implementations.

You should not be creating complexity and awkwardness simply for the
sake of the fun of it.  The engineering solution is simple and elegant.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 20 Jul 2001 13:50:26 -0500

Martin has expressed some concerns over the use of additional OIDs
in IAKERB. Jonathan has respond. 

So far I have not heard from anyone else on this issue, as to weather
this presents a problem with the draft which is in extended last call
till Monday. 

I am looking for consensus, and have not heard from many WG members.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 20 Jul 2001 12:24:03 -0700

The advantage of separate OID's is it allows a SPNEGO app to have secure
negotiation. Given separate OID's, is there any way that Martin's problems
can be solved as well? Is there any problem with allowing iakerb under the
rfc1964 OID as well as under its own OID's? So the rfc 1964 code could fall
back to iakerb under certain failure scenarios and from the app's point of
view, nothing has changed? (In this latter case, we assume that all the
rfc1964 responders also support iakerb or there is some out of band way for
the initiator to learn that the rfc1964 responder does not support iakerb).

Jonathan

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 20 Jul 2001 12:25:33 -0700

>overcome a lack of direct IP connectivity to the KDC.

Which mechanism should be the default is a local policy decision.

>unnecessary to use seperate mechanism OIDs for IAKERB.

The advantage of using separate mechanism OID's is that you can obtain
secure negotiation using SPNEGO. There is no mechanism to accomplish this
in Kerberos alone. If the responder doesn't support IAKERB and receives an
IAKERB init token from the initiator, the only secure way to fall back to a
lesser mechanism is with SPNEGO.

>      laptops, portables, dialup from home, etc.)

Sounds like a nasty config problem. I'm wondering if the following approach
could work: if I understand correctly, you want the rfc 1964 code to
automatically revert to iakerb on certain failure scenarios. Is there a way
to revert to iakerb within the rfc1964 library, but still keep the separate
OID's for the above reasons? The iakerb spec. doesn't outlaw using iakerb
with the rfc1964 OID as well. Of course, there is no way of enforcing that
rfc1964 implementations will support iakerb (the new token types). What are
the issues with allowing iakerb to happen under the rfc1964 oid as well as
under it's own oid's?

>     current network connectivity.

With SPNEGO, the responder picks so there is no need to tag by target name.
The app you describe isn't scaleable from a management perspective. 

>Kerberos extension will not add any value but cause significant problems

It allows for secure negotiation. 

>gained in a more backward-compatible fashion)?

secure negotiation

>sake of the fun of it.  The engineering solution is simple and elegant.

We're not. 

Jonathan

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jul 2001 17:58:13 +0200 (METDST)

> Which mechanism should be the default is a local policy decision.

I'm sorry, but this is ridiculus.  There simply is no policy involved
and I don't expect anyone who implements that to create a mandatory
to configure prompt for the admin to choose "his" policy.

It will almost always be a network connectivity issue and I don't
see any good reason for a client to propose IAKERB whenever rfc-1964
will work, and neither why a client should offer rfc-1964 along
with IAKERB when it knows reliably that it will not be able to
use rfc-1964 -- the reason why it proposes IAKERB at all.

> lesser mechanism is with SPNEGO.

I explained it already, but well, here we go again:

The "P" for protected is not any kind of pixie dust as you seem to
imply.  The reason why "P" was introduced in the original SNEGO
proposal was to prevent an attacker to manipulate the handshake 
and coerce the peers to select a "weaker" common gssapi mechanism
than what they normally would have chosen.

The security consideration section of the SPNEGO document (rfc2478)
mentions it -- it could have been more precise about that this is
the only protection that is provided and the only reason for
which the "P" part was added:

  5.  SECURITY CONSIDERATIONS

     When the mechanism selected by the target from the list supplied by
     the initiator supports integrity protection, then the negotiation is
     protected.

     When one of the mechanisms proposed by the initiator does not support
     integrity protection, then the negotiation is exposed to all threats
     a non secured service is exposed. In particular, an active attacker
     can force to use a security mechanism which is not the common
     preferred one (when multiple security mechanisms are shared between
     peers) but which is acceptable anyway to the target.

     In any case, the communicating peers may be exposed to the denial of
     service threat.

Thinking about this for a little should open your eyes.  What mechanism
is going to put the MIC on "IAKERB proxy", "IAKERB minimal messages"
and "rfc-1964" mechanism in the SPNEGO handshake?

Since IAKERB is itself not a gssapi mechanism, but an extension to
rfc-1964 Kerberos, it would be the EXACT SAME rfc-1964 mechanism that
would MIC the SPNEGO mechanism list in all three cases.

Knowing this, it should be easily conceivable that the same can
be easily designed into an SPNEGO handshake inside rfc-1964 tokens,
thus relieving Kerberos implementors from the necessity to implement
a full-fledged SPNEGO.

> the issues with allowing iakerb to happen under the rfc1964 oid as well as

Really BAD idea.  We're looking for broad interoperability.
Allowing both (besides requiring a significantly more complex spec)
will cause interoperability problems.

There should only be one way to do it!

> The app you describe isn't scaleable from a management perspective. 

Maybe we are talking of completely different proposals here.

I am talking about IAKERB, an extension of rfc-1964 Kerberos
originally proposed by Mike Swift (working for Microsoft at that time)
that can be used with gssapi-style message exchange in a situation
where the client is unable to communicate with the KDC to acquire
tickets.  One of the scenarios he mentioned was for the initial
authentication during dialup to an ISP or dialin to a network where
not even an IP-Address had been assigned to the client.  Other uses
where clients behind firewalls.

> >gained in a more backward-compatible fashion)?

Deceiving argument, but as explained doesn't apply to IAKERB.

Can you come up with *any* benefit?

-Martin