Subject: [Ietf-krb-wg] enctypes take 2 - consensus call

From: Leif Johansson <[email-masked]>
Date: Tue, 10 Nov 2009 06:49:43 +0100

I talked this over with Sam yesterday and our suggestion is that we
keep the attribute as it is and make its semantics more explicit by
stating that it is used for explicitly limiting to the listed enctypes
in _all_ cases where keys are used in kerberos. In other words the
attribute represents the most basic form of a policy for enctypes.

If you want something more complex such as allow/deny semantics or
such things then you define a policy object (which the text already
sais basically).

Apart from the we propose adding text to the KeySet object saying
that in addition to the policy attribute the presence of a key with
a certain enctype in a keyset implies that the server supports that
enctype for the given principal.

Does that sound like something we can reach consensus around?

	Cheers Leif
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Wed, 11 Nov 2009 00:57:10 -0500

> attribute represents the most basic form of a policy for enctypes.

That sounds reasonable to me, but I would like some clarifications.
This is not limited to the selection of keys for ticket issuance?
Does it also include things like the behavior of any KDC
administration service in generating new long-term keys?  Are policy
objects, etc. allowed to override it?

> enctype for the given principal.

This is consistent with the behavior of existing implementations,
though I can see scenarios where you might want to have only one key
for a service yet allow the KDC to issue session keys of several
possible enctypes for that service.  I suppose that sort of policy is
implementable by using the principalAllowedEnctype attribute to
augment the set of allowable session key enctypes for that service
principal.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Nov 2009 07:16:31 +0100

> objects, etc. allowed to override it?

The semantics would be that the attribute _if present_ limits *all*
uses of enctypes for the principal. If you don't like the expressive
power of this you do an extension of the info model or a policy
object.

> augment the set of allowable session key enctypes for that service

Yes. As I said we're trying to find the 80/20 sweet spot for policy
here (or maybe 90/10).

	Cheers Leif

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 11 Nov 2009 18:24:52 -0800

> power of this you do an extension of the info model or a policy

This would allow you to specify a weak set of keys for a specific,  
obsolescent service without affecting anything else?

Above is just a nit.  I think I'm in favor.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Nov 2009 04:23:53 +0100

> obsolescent service without affecting anything else?

Yes assuming the service had a separate principal.

	Cheers Leif