Subject: [kitten] Consensus Calls

From: Shawn Emery <[email-masked]>
Date: Tue, 06 Sep 2011 14:47:26 -0600

During the kitten WG session at IETF 81 there were a number of consensus 
calls made in the room.  To the benefit of those that were not there 
physically or virtually, there are a number consensus calls to be made 
on the list.  Please respond to me individually or on the list depending 
on the circumstances.  The calls end in two weeks - 9/20/11.  Please 
refer to the session notes and slides for back ground information:

1. In regards to replay cache issues do you believe that this should be 
resolved by any/all of the following:

(Please refer to http://www.ietf.org/proceedings/81/slides/kitten-1.pdf)
(slides 2 & 3)
1.1.1 Increase replay cache performance?
1.1.2 Do not increase replay cache performance?

(slide 4)
1.2.1 Use implicit 3rd leg initial security context exchange?
1.2.2 Do not useimplicit 3rd leg initial security context exchange?

(slide 5)
1.3.1 Use explicit 3rd leg initial security context exchange?
1.3.2 Do not use explicit 3rd leg initial security context exchange?

(slides 9 & 10)
2. In regards to exporting partially established security contexts:

2.1 Should create a utility function to export partial security contexts?
2.2 Should not create a utility function to export partial security 
contexts?

3. In regards to issues with GSS-APIu2v1:

(Please refer to http://www.ietf.org/proceedings/81/slides/kitten-2.pdf)
(slide 2)
3.1 Who believe that memory management is an issue and should be fixed?
3.1 Who do not believe that memory management is an issue and should be 
fixed?

Shawn.
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Sep 2011 17:39:32 -0500

> 1.1.2 Do not increase replay cache performance?

This can be entirely a local implementation issue, therefore the only
consensus issue would be whether to go for an FYI describing some fast
rcache designs.  I would be happy with such an FYI and would
contribute text, but could not edit.

> 1.2.2 Do not use implicit 3rd leg initial security context exchange?

I believe a req_flag denoting implicit 3rd leg in GSS sec context
token exchanges could be generally useful, but I've become very
skeptical of implicit 3rd leg for Kerberos -- because the flag would
have to be critical in GSS mech contexts and non-critical in raw krb5
contexts I just don't see how to make this work reliably.  (If
inserting an entry into the rcache but not checking for dups were
significantly faster than doing both, then implicit 3rd leg would have
some value for Kerberos, but most of the time there will be no such
significant performance difference.)

Count me as a no to implied 3rd leg then (i.e., "yes" to 1.2.2).

> 1.3.2 Do not use explicit 3rd leg initial security context exchange?

I would very much like this, so count me as supporting this (yes to 1.3.1).

I would also like to add another consensus call, though this one would
fall squarely in KRB-WG's purview: whether to allow probabilistic
rcaches only (i.e., ones that have zero false negatives but a non-zero
false positive rate).  Combined with a "retriable" AP exchange feature
for the krb5 GSS mech this would work quite well.  (Specifically I
have a Scalable Bloom filter in mind as a probabilistic rcache.)

> 2.1 Should create a utility function to export partial security contexts?

We should add a utility function to create *encrypted* partially
exported security context tokens.

Separately we should also agree that GSS_Export_sec_context() should
be allowed to export partially-established security contexts (with no
guarantee that they can be re-imported).

> 3.1 Who do not believe that memory management is an issue and should be

I think it's too soon to tell.  We need to hear from Sam as to whether
he's found a way to make the mechglue and providers share a single
allocator irrespective of other allocators that might be in use in the
application on *all* major operating systems.

There were other issues, however, that might lead us to wanting either
a significant update of GSS-API v2u1 or else into a completely new
version of the API.  But here too I think it's too soon to establish
consensus.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Thu, 08 Sep 2011 01:07:24 -0400

On Wed, 2011-09-07 at 18:39 -0400, Nico Williams wrote:
> I've become very skeptical of implicit 3rd leg for Kerberos

I think I agree, for two reasons:

1. It's the acceptor who has to say whether an implicit third leg will
be expected (the initiator's promise is not really interesting), but
gss_accept_sec_context has no req_flags argument, so there's no easy way
for the acceptor to speak.

2. (Rephrasing Nico here:) You want to make sure that authenticators
aren't used with other protocols which aren't replay-proof.  For
instance, ssh gssapi-with-mic is replay-proof, but if the ssh
authenticator isn't replay-cached, an attacker could conceivably steal
the ssh authenticator and replay it against auth-only rlogin.

> > 1.3.1 Use explicit 3rd leg initial security context exchange?

At this point I don't know exactly how this would work, and I don't know
if it solves the criticality issue.

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Sep 2011 00:13:36 -0500

> if it solves the criticality issue.

You can make the explicit 3rd leg flag critical in all cases.  Well,
right, authz-data in Kerberos are supposed to be critical, but that's
not how it's widely implemented, so if you have old libraries... yeah.
 We're stuck.

The good news is that clusters can probably be made to use implicit
3rd leg (with no negotiation needed) in all clusterable application
protocols, so that perhaps for clusters there's nothing special to be
done, and for non-clusters we can just rely on fast rcache techniques.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 08 Sep 2011 02:39:16 -0400

> 1.1.2 Do not increase replay cache performance?

I believe that replay caches need to be avoided.

> 1.2.2 Do not useimplicit 3rd leg initial security context exchange?

Do not use implicit 3rd leg.

> 1.3.2 Do not use explicit 3rd leg initial security context exchange?

Use explicit 3rd leg

> 2.2 Should not create a utility function to export partial security

I am not opposed but do not have a strong opinion in favor either.

> 3.1 Who do not believe that memory management is an issue and should be

I believe that memory management is an issue and should be fixed.  When
memory is allocated by a module it should be freed by that same module.
  It is not going to be possible for an allocator in one module to be
dictated by another module.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2011 16:35:08 -0400

Nico, to the extent that some of these issues affect the Kerberos
mechanism, would it make sense to discuss in a krb-wg session at IETF
82?
This assumes that kitten permits the generic feature.

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Sep 2011 16:14:21 -0500

> This assumes that kitten permits the generic feature.

Yes.

BTW, I'm also coming around to the idea that implicit 3rd leg works
because where it doesn't, you have bigger problems anyways.

Nico
--