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

[Leif Johansson-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr4/vcACgkQ8Jx8FtbMZndjdgCcDpVbnAetZd0wqtNEBBw55cF/
ghsAoLd0WdWFxQ+L6IRcBLQpGftHZyCf
=M4Ib
-----END PGP SIGNATURE-----
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Tom Yu]

Leif Johansson <leifj@...> writes:

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

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?

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

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
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Leif Johansson-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Yu wrote:

> Leif Johansson <leifj@...> writes:
>
>> 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.
>
> 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?

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.

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

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

        Cheers Leif

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr6VrwACgkQ8Jx8FtbMZneHbACdFYWh03IAfifs6tpaWc7Rh/h9
ANoAn12PNHkxaKK+DQ+uCaogCxlCCXib
=ENlD
-----END PGP SIGNATURE-----
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Henry B. Hotz]

On Nov 10, 2009, at 10:16 PM, Leif Johansson wrote:

> Tom Yu wrote:
>> Leif Johansson <leifj@...> writes:
>>
>>> 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.
>>
>> 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?
>
> 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.

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.
Henry.B.Hotz@..., or hbhotz@...



_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Leif Johansson-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

Yes assuming the service had a separate principal.

        Cheers Leif

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr7f8UACgkQ8Jx8FtbMZndn+gCgjFiLub5YSWDL/PFiL7Ar2585
K6sAoIRq45/iDnRjMCxfw6gxieoxQ0QZ
=Mxqr
-----END PGP SIGNATURE-----
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@...
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg