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

From: "Paul Leach" <[email-masked]>
Date: Mon, 23 Jul 2001 10:12:29 -0700

A client can/will know to use IAKERB when it cannot get a ticket for a
service in the normal way (tracing the trust path from its realm's KDC
to the service's realm's KDC). Assuming that the issue isn't temporary
connectivity loss, if the normal way doesn't work, IAKERB is the only
thing that will.

It would be nice for the client to know that service supports IAKERB --
even though it would be a bug for the service to crash or misbehave when
presented with IAKERB messages, it would still be polite to not send
them if they weren't supported.

There is also the question of whether the client might be able to avoid
the expense of trying to get a ticket in the normal way before switching
to IAKERB. It can do this if it knows a priori that there is no trust
path to a given realm. That seems to me to require client-side
configuration. Whether that counts as "policy" I'm not sure -- but
perhaps that's the source of the contention here.

Paul

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jul 2001 20:16:30 +0200 (METDST)

> perhaps that's the source of the contention here.

Thanks for this information, Paul.

It seems to confirm my assumption that there is very little need
for negotiation and very strong need for determination of the
current network connectivity.

Currently there are gssapi based applications that do conciously
select among gssapi mechanisms by requesting specific mechanisms
by OID.  Such application would be precluded from benefitting
an IAKERB Kerberos extension with independent mech OID.  And
"simply adding" new mechanism OIDs to those that they know
wouldn't work, because the choice between IAKERB and rfc-1964
depends primarily on network connectivity.

Applications that do select mechanisms by OID are perfectly valid.
In fact, as soon as a gssapi-based application creates, uses
(e.g. pre-populates) ACLs containing binary canonical names,
it will start dealing with specific mechanism OIDs.

Everyone is free to invent new, independent gssapi mechanisms,
but IAKERB as a Kerberos extension using distinct gssapi mechanism
OIDs is a pig that wont fly (within the GSS-API design).

-Martin