Subject: Toughts on IAKERB and stackable pseudo-mechs

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Nov 2006 09:28:46 -0600

The chief problem to resolve in making a mechanism like IAKERB stackable
is this: how to communicate the raw credentials it acquires to the
mechanism stacked below.

The obvious answer is to use a GSS-API CREDENTIAL HANDLE, but the
question is how to get one given only a Kerberos V Ticket and session
key.

And the answer to that is that a number of implementors have been
pursuing mechanism-specific extensions like gss_krb5_acquire_cred_with_X().

These extensions still go through multi-mechglue, in some way.

I have a workspace with a gss_krb5_acquire_cred_with_ccache() that will
soon enough go into OpenSolaris, for example, and we already have
extensions like gss_acquire_cred_with_password().  I believe MIT and
Heimdal have similar sorts of extensions.

So, as long as such extensions extensions are provided by the
multi-mechglue and the concrete mechanisms then IAKERB can be a
stackable mechanism.

Note too that specifying IAKERB as a stackable mechanism does not force
anyone to implement it that way -- you can still implement it
monolythically, as one might implement the mechanism Larry presented.
Conversely, one might implement the mechanism presented by Larry
non-monolythically much as one might implement a stackable mechanism
non-monolythically.

Something much more generic than IAKERB, like the IP-tunneling
pseudo-mechanism that Sam posited at the meeting yesterday, cannot be
implementated in this way, as there just is no way for such a mechanism
to transparently tunnel traffic generated by the mechanism stacked
below.

Nico
-- 

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