Subject: Interesting multi-mech/multi-bindings exported sec context token issue

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Nov 2005 18:12:17 -0600

Exported security context tokens, unlike exported name tokens, have no
header identifying a mechanism or anything else.

Multi-mechanism non-monolythic implementations of the GSS-API can deal
with this by adding a header to the token as output by a mechanism and
then stripping it off prior to calling the mechanism to import it.

That works well enough, and it is what Solaris' libgss does.

But think now of a Java implementation where some mechanisms are
implemented in Java, and some are accessed through a Java bridge to an
independent implementation through C bindings.

This approach then doesn't work in such a situation because a security
context token exported through the Java bindings but for a mechanism
accessed through the bridge to the C bindings cannot then be imported by
an application using only the C bindings -- the C implementation won't
expect the header added by the Java bindings.

Thoughts?

Nico
-- 

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Nov 2005 19:47:19 -0600

> Thoughts?

I should add my thoughts on how to solve the problem while I'm at it:

 - RECOMMEND the use of a token header, much like the exported name
   token header, for exported security context tokens.

   I say RECOMMEND but would rather REQUIRE.

Nico
--

---

From: Wyllys Ingersoll <[email-masked]>
Date: Thu, 17 Nov 2005 09:54:22 -0500

>    I say RECOMMEND but would rather REQUIRE.

This sounds reasonable to me.

-Wyllys

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 17 Nov 2005 11:15:18 -0500

>    I say RECOMMEND but would rather REQUIRE.

Nico:

This sounds like another topic for which text should be added to
GSSAPIv2u1 Clarifications.

I agree with you that exporting tokens with a header should be
strongly recommended.   You will need to specify what the header
format is.

One thing that the Java implementation can do in this case because
it is binding to a particular implementation is to keep track of
whether or not a header is being used and strip it off itself
or add it as needed.

Even assuming that such a change is made for all future gss library
distributions it will be the case that the existing distributions
will still exist for a long time to come.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Nov 2005 12:50:28 -0600

> strongly recommended.   You will need to specify what the header

Yes.

> whether or not a header is being used and strip it off itself

If it knows what the implementation is, yes, if not then it's a
heuristic (does the token begin with what looks like the right header?).
We might be able to improve that by adding a checksum.

> will still exist for a long time to come.

Of course.  In such cases implementors could say "upgrade" or "apply
this patch" (or do what you suggest above).

Thanks.  I'll write up some text.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 Nov 2005 21:16:54 +0100 (MET)

> header identifying a mechanism or anything else.

The reasons why exported name tokens have a header identifying the
mechanism was to prevent collisions of ACL entries between two
independent gssapi mechanisms for different users.

Since ACLs on objects can be fairly long-lived, we thought it would
be a very good idea if they were guaranteed to be constant over
time (reliably backwards compatibility for different revisions
of a gssapi mechanism).  Ultimately, a full spec for the format
of the exported name token should become part of a gssapi mechanism
spec (as done in rfc1964) so that ACL entries become independent
from the particular mechanism implementation which created them
and can be used by other, independent implementations of this
mechanism as well.

Exported security context tokens were created with a very limited
scope in mind.  The purpose was to be able to pass security contexts
around between processes (somewhat similar to passing established
network sockets between processes).  Since gssapi security contexts
should have a limited lifetime anyway, and performance of the security
context transfer operations was deemed important, there were
no requirements defined for contents of security context tokens.

Security context tokens in GSS-API v2 are by design extremely non-portable.
They're very likely not transferable among different implementations
of the same gssapi mechanism, likely not transferable across host boundaries
and they may have additional restrictions (like when a context is bound
to a hardware credential, and the access to these credentials is protected,
then it may be that the context can not be used by a process running
under a different user, etc.

Your scenario where you want to transfer a gss-api security
context that you exported in Java over to pure-C code or the other
way round is something that will NOT work in general, and I see
no good reason why it should (no reason to burden mechanism
implementors).

As you noted, you could address this issue in your multi-mech glue
by adding a particular framing/container on context export and strip
that container on context import.  You're free to do that today and
it's fine with the GSS-API spec if some mechanism do this.

*I* completely dislike the idea of defining such a framing/container
at the GSS-API level.  Even at the mechanism level I consider it
a bad idea, because we do *NOT* want to standardize the entire contents
of the security context token, not even at the mechanism level!

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Nov 2005 13:16:01 -0500

I think you're even more fundamentally challenged because there's no
reason to believe two different implementations of the mechanism will
have compatible export tokens.

Seems like at the same point you add support for reading another
implementation's token you could add support for the java wrapper.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Nov 2005 13:17:19 -0500

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> Nicolas Williams wrote:
    >> - RECOMMEND the use of a token header, much like the exported
    >> name token header, for exported security context tokens.
    >> 

    Jeffrey> Nico:

    Jeffrey> This sounds like another topic for which text should be
    Jeffrey> added to GSSAPIv2u1 Clarifications.

I totally don't see the point.  The header would need to describe the
mechanism implementation, not just the mechanism.  We don't have a
good way to do that.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Nov 2005 14:24:25 -0600

On Thu, Nov 17, 2005 at 09:16:54PM +0100, Martin Rex wrote:
> [...]

No question.

> Security context tokens in GSS-API v2 are by design extremely non-portable.

I think there may be a false assumption here.  More on that later.

> no good reason why it should (no reason to burden mechanism

Not quite.

The scenario is that an exported security context token made by a given
implementation cannot be re-imported by that SAME implementation WHEN in
one case that implementation is wrapped by a multi-mechanism library and
in the other case it is not.

I do see good reason why this should work.

> it's fine with the GSS-API spec if some mechanism do this.

See above.

> of the security context token, not even at the mechanism level!

We're talking about new mechanisms that may share the existing Kerberos
V mechanism's [RFC4121] per-message tokens.  Such mechanisms will have
much the same exported security context state, with differences
appearing only as a result of extensions relating to naming.  I see no
reason why we should not be able to have a standard exported security
context HEADER, plus SOME standard exported security context CONTENTS
for mechanisms that share a specification for per-message tokens.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Nov 2005 14:32:04 -0600

> mechanism implementation, not just the mechanism.  We don't have a

For the problem at hand it suffices to describe only the mechanism OID.

This is because the same implementation is being used in two cases, but
in one case wrapped in a multi-mechanism framework and in the other not
(or with a different multi-mechanism framework).

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Nov 2005 15:45:48 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> For the problem at hand it suffices to describe only the
    Nicolas> mechanism OID.

    Nicolas> This is because the same implementation is being used in
    Nicolas> two cases, but in one case wrapped in a multi-mechanism
    Nicolas> framework and in the other not (or with a different
    Nicolas> multi-mechanism framework).

It seems like it is best to handle as a local matter at least until we
standardize export tokens for mechanisms.

Adding advice that within a platform people should figure out how to
handle this issue also seems fine.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Nov 2005 14:52:42 -0600

> handle this issue also seems fine.

That is the minimum.  I'd add that I would recommend doing that.

Nico
--