Stacking order

[Nicolas Williams <Nicolas.Williams at sun.com>]

Sam asked how to avoid having two semantically equivalent composite
mechanisms that differ in stacking order.  This was in the context of
IAKERB as a stackable pseudo-mechanism.  Sam pointed out that CCM and
IAKERB could be stacked together in either order on the Kerberos V
mechanism and the semantics of the resulting two composite mechanisms
should be the same.

I just posted a note about close coupling between IAKERB and the
Kerberos V mechanism -- that to implement IAKERB non-monolythically one
would need a krb5 mechanism-specific GSS extension.  This does not mean
that IAKERB must be stacked directly above the krb5 mech as the CCM mech
might provide such an extension too as a simple pass-through, but it
does suggest that this close coupling should lead to composition rules
for IAKERB like:

 - IAKERB MUST be stacked only above a concrete mechanism
 - IAKERB MUST be stacked only above a mechanisms that has the
   GSS_C_MA_ACQ_CRED_W_KRB5_TIX attribute[*]

[*] which I just made up and which would mean that the mech provides a
    gss_acquire_cred_with_krb5_tickets() extension or some such.


Nico
-- 

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten