Subject: Stacking order

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

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

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

>    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
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 9 Nov 2006 01:33:06 -0800

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:[email-masked]] 
Sent: Wednesday, November 08, 2006 7:55 AM
To: [email-masked]
Subject: Re: Stacking order

 - CCM
 - compression

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 11:27:57 -0600

On Thu, Nov 09, 2006 at 01:33:06AM -0800, Liqiang(Larry) Zhu wrote:
> enough.

What's WS-KRB-HEADER?

>         It can only be stacked over variants of Kerberos protocols: U2U
> or RFC4120 Kerberos.

That's OK.

> stackable mechanism. The complexity does not justify the benefits at

All you have to do to make it a stackable mechanism is this:

a) make the OIDs of the mechs composed with IAKERB be ==
	OID of IAKERB || OID of concrete mech.

b) don't use AP-REQ/AP-REP directly, but instead use the context tokens
   of the concret mechanism.  Which in this case means using AP-REQ/
   AP-REP with the GSS OID header pre-pended.

Of course, for something as closely tied to the underlying mechanism as
IAKERB there would be complexity in implementing as a stackable
mechanism: the need to provide GSS extensions for communicating
credentials acquired by IAKERB to the underlying mechanism.

But the beauty of stackable mechanisms is this: you can choose to
implement them monolythically, or generically -- your choice.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Nov 2006 15:53:45 -0500

> of each stackable pseudo-mechanism's composition rules.

Really, not only do you not want CCM to stack on top of compression, you 
pretty much want compression to stack above anything whose per-message 
tokens might involve encryption of the data.  You probably want CCM to 
stack fairly high, for similar reasons -- if you have a bunch of mechanisms 
whose per-method tokens involve expensive crypto operations, and CCM's 
purpose is to avoid using them, then you want CCM to stack high enough to 
do that.

On the other hand, things like multiple authentication and IAKERB can 
really stack nearly anywhere, but for practical reasons want to be near the 
bottom of the stack.

In fact, after some discussion, I'm not sure making IAKERB stackable is 
such a good idea after all.  The reason is that there needs to be fairly 
tight communication between IAKERB and the underlying Kerberos 
implementation used by the krb5 mechanism.

Ordinarily, as part of building an initial context token, the krb5 
mechanism makes a call to the underlying Kerberos implementation to build 
an AP-REQ, which in turn may result in the Kerberos library communicating 
with a KDC (behind the back of both the application and the GSS mechanism) 
to obtain the needed service ticket.  When IAKERB is in use, it is 
reasonable to assume that communicating directly with the KDC won't work; 
instead, such communication must be mediated by IAKERB, which carries it in 
context tokens transported by the application.

That essentially means the Kerberos API is going to need some form of 
extension which allows the library to hand KDC traffic to the caller for 
transport, instead of opening its own connection.  The GSS mechanism will 
need to provide such a callback, and make use of a mechanism along the 
lines of PAM_CONV_AGAIN/PAM_INCOMPLETE to allow the callback to return 
control back through the Kerberos library to the mechanism proper, which 
can construct a context token to be returned to the application.

Now, as long as IAKERB is a concrete mechanism, rather than a layer stacked 
on top of a Kerberos mechanism, this whole interface can remain private 
between the IAKERB mech and the Kerberos implementation (which need not 
even be exposed to applications).  However, if IAKERB is stackable, then 
the interface between it and the mech stacked below must be well-defined, 
and must include a way for the Kerberos implementation to pass KDC traffic 
up through the concrete Kerberos mechanism to the stacked IAKERB mechanism, 
which encapsulates it in a context token.

> it safe, ignoring the problem.

I don't think ignoring the problem is likely to be unsafe, though it may 
create inconvenient interoperability issues.  Consider GSS-API users like 
SSH key exchange or SASL GS2, where GSS-API mechansim OID's are mapped into 
the available namespace by an irreversible function, in order to avoid 
multi-level negotiation issues.  If multiple stacking orders are possible, 
then the number of composite mechanisms explodes, giving these frameworks a 
huge number of mechanism numbers to deal with -- and some of them have 
limited space for expressing the set of available mechanisms.

Perhaps we just need a last-resort rule, such as ordering otherwise 
equivalent mechanisms by OID, such that 1.3.6.1.4.1.22484.42.4.1 always 
stacks above 1.3.6.1.4.1.22484.42.4.2.

> we discover that new rules are needed.

It's easy to come up with a regular way to express dependencies.  Coming up 
with a way to express stacking order is harder, and will require some 
thought.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2006 15:50:30 -0600

> stacks above 1.3.6.1.4.1.22484.42.4.2.

I think so too.

> It's easy to come up with a regular way to express dependencies.

The language for the rules is easy.  I'm thinking of:

 - MUST     stack above mechanisms with <mech attr set>
 - MUST NOT stack above mechanisms with <mech attr set>
 - MUST     stack above any of <mech set> only
 - MUST NOT stack above any of <mech set>

 - SHOULD     stack above mechanisms with <mech attr set>
 - SHOULD NOT stack above mechanisms with <mech attr set>
 - SHOULD     stack above any of <mech set> only
 - SHOULD NOT stack above any of <mech set>

The SHOULD/SHOULD NOT rules are used when computing a set of composed
mechanisms, but not when validating a composed mechanism (i.e., you can
use such mechanisms but the framework won't advertise them unless told
to by local configuration).

>                                                                   Coming up 

Well, no, the rules for each stackable mechanism can be constructed so
that by and large only sensible stacks are possible, provided that we
properly model mechanism features.

Only where we have morally equivalent composite mechanisms do we need
some sort of tie breaker -- your proposal is to use an OID sort order
for that, which seems fine by me.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2006 16:12:36 -0600

On Tue, Nov 21, 2006 at 03:53:45PM -0500, Jeffrey Hutzelman wrote:
> tokens might involve encryption of the data.

If you want your data compressed then you want the reverse: compression
must stack above (before) CCM.  That's because CCM does not use the
per-msg protection services of the mech it stacks above of.

And yes, compression has to come before encryption.  So compression
mechs have to stack above, say, a stackable PFS mech.

We can express these constraints using rules like I just described in my
previous post.

>                                               You probably want CCM to 

Right.

> really stack nearly anywhere, but for practical reasons want to be near the 

Yes.

> implementation used by the krb5 mechanism.

Oh, it can be done.  First, stackable doesn't mean that you must have a
non-monolythic implementation.  Second, I can think of a non-monolythic
implementation anyways, imagine a pair of functions like this:

   GSS_Set_proxy_callback_to_cred()
   GSS_Get_proxy_callback_to_cred()

for setting/getting a callback function that mechs like krb5 can use to
send/receive messages to a KDC.

Then IAKERB would be able to provide proxy services to the krb5
mechanism without having to be so tightly bound with it
implementation-wise.

Now, making this callback generic enough that it could cover proxied
communications with KDCs, OCSP responders, CRL DPs, SACRED servers and
what not, that would be the trick :)  (But no worries: just have
different callback for each of those purposes.)

Similarly, we could design a generic proxy mechanism, but every addition
of a new protocol to proxy would require exchanging protocol-specific
routing/authentication information with the proxy.

These callbacks and related functions could be seen as implementations
details.

What I'm trying to illustrate is that making IAKERB "stackable" does not
require non-monolythic implementation, but that it does make clean
non-monolythic implementation possible.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2006 16:53:55 -0600

> which encapsulates it in a context token.

If by "well-defined" you mean "defined in a Standards-Track RFC" then I
don't agree that it has to be done that way but I sure don't mind doing
it only as an abstract API for the purpose of having a more formal
description of how the mechanism works.  But I think I would object to
any *requirement* that C-bindings be standardized just to have IAKERB be
a stackable mechanism.