RE: Stacking order

["Liqiang(Larry) Zhu" <lzhu at windows.microsoft.com>]

The use of WS-KRB-HEADER header clearly means that IAKERB is not generic
enough. It can only be stacked over variants of Kerberos protocols: U2U
or RFC4120 Kerberos.

I suspect it might be a bit over engineering to specify IAKERB as a
stackable mechanism. The complexity does not justify the benefits at
this point.

-- larry


-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams at sun.com] 
Sent: Wednesday, November 08, 2006 7:55 AM
To: kitten at ietf.org
Subject: Re: Stacking order

On Wed, Nov 08, 2006 at 09:34:37AM -0600, Nicolas Williams wrote:
>  - 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[*]

The result should be that while both IAKERB and CCM will gladly stack
above krb5, and CCM will gladly stack above IAKERB-krb5, IAKERB will not
stack above CCM-krb5.

It may not always be possible to purposefully construct composition
rules in order to prevent multiple equivalent compositions.  But in
practice the number of stackable pseudo-mechanisms will be small; we've
posited a small number of them:

 - CCM
 - compression
 - bound concurrent authentication of multiple client principals
 - IAKERB

 - GSS-TLS w/ krb5 per-msg tokens could easily be constructed as a
   stackable pseudo-mechanism if there was a krb5-specific GSS extension
   for creating fully established security contexts out of key material
   (and NAME objects, which in the case of GSS-TLS would be
   GSS_C_NO_NAME -- the app would see the NAME objects from GSS-TLS,
   which would correspond to the asserted PKIX cert names).

I can probably think of afew more.

We can construct composition rules so that CCM never stacks above
compression, multi-auth mechs never stack above CCM, IAKERB never stacks
above CCM and GSS-TLS never stacks above CCM.

It requires having mechanism attributes that reflect what the mechanisms
do (e.g., compression transforms wrap token data, and CCM would lose
such transformations as it doesn't use the underlying mech's per-msg
tokens for its own per-msg tokens when the channel is bound, therefore
CCM does not want to stack above compression) and careful consideration
of each stackable pseudo-mechanism's composition rules.

If the rules we construct today leave us with a handful of equivalent
composite mechs that differ only in stacking order a few years down the
line when new stackable mechs come along, well, that wouldn't be so bad,
and can be dealt with in any of a number of ways, including, if we think
it safe, ignoring the problem.

There might be an argument here for having a formal language for
composition rules, so that rules can be added through configuration when
we discover that new rules are needed.

Nico
-- 

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

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