Subject: Re: [Ietf-krb-wg] Supported enctypes needs its own thread (Re: Comments on informational model)

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Nov 2009 23:37:54 -0500

--On Thursday, October 29, 2009 11:02:01 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> Sam, I don't quite agree.  As an administrator I'd like to be able to
> set policy for which entypes the KDC will access in pre-auth (including
> PA-TGS-REQ) and which enctypes the KDC will accept for Ticket session
> keys and Ticket encryption keys.  I'd be happy to do so via explicit
> lists or via lists constructed from rules ("no weak enctypes", "only AES
> enctypes", ...).

As someone who actually administers a production Kerberos realm, there are 
in fact three policies I want to be able to set:

(1) enctypes used when setting passwords for users
(2) enctypes used when keying services
(3) "weak" enctypes which must never be used

Generally (1) and (2) will be the same, but in practice they seem to change 
at different times.

Enforcement of (3) is done primarily at the KDC, but must unfortunately 
also be done in clients and services, particularly those which handle 
initial authentication using long-term keys derived from passwords.

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 09:47:58 -0600

> Generally (1) and (2) will be the same, but in practice they seem to change 

You should want to control enctypes accepted/used.  But why should you
want to control enctypes available?  For password-derived keys the only
reason that I see is: to avoid off-line dictionary attacks should the
KDB be compromised... but you have such much bigger problems in that
case that I don't think that's a problem.

User principals should get "all enctypes supported by the KDC software",
and service principals should get "all enctypes supported by the
software running that principal's service".

Actual enctype usage policies should apply in the AS, TGS and AP
exchanges, not during key maintenance.

> initial authentication using long-term keys derived from passwords.

Yes.  And if denying a service keys for weak enctypes helps, great
(though the same won't work for user principals, since they don't carry
their keys and don't know the enctypes for which they have keys).  But I
think you'll need configuration, or better, obsolescence, to get rid of
weak enctypes.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Nov 2009 12:13:48 -0500

--On Tuesday, November 10, 2009 09:47:58 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> > lists or via lists constructed from rules ("no weak enctypes", "only
>> > AES enctypes", ...).
>>
>> As someone who actually administers a production Kerberos realm, there
>> are  in fact three policies I want to be able to set:
>>
>> Generally (1) and (2) will be the same, but in practice they seem to
>> change  at different times.
>

Says you.  In practice, this is even usually true.  But not always. 
Furthermore, for users (i.e. things with passwords), configuration includes 
not just enctypes but salt strings and string-to-key parameters.  Does this 
enctype need a v4- or v5-salted key or both?  Does it need a key prepared 
with AFS's alternate DES string-to-key algorithm?  How many PRF iterations 
should be used in deriving an AES key?

Further, in real life most of us like to test new functionality in a 
controlled way before exposing our users to it.  For new enctypes, that 
includes deploying a KDC supporting a new enctype but only configuring a 
small set of users and services to use it.

> software running that principal's service".

In practice, the way that's done is that nearly all services in a realm run 
similar software and support the same enctypes, and the mechanisms that key 
services know what those are and apply the same rules to all services.  Of 
course, there are always a few exceptions, which must be configured 
explicitly.

> exchanges, not during key maintenance.

Yes, but it turns out that those policies are simple:

(1) Never use prohibited "weak" enctypes

That's it. Everything else is part of the protocol, or obvious:

- Don't use a reply key enctype not supported by the client.
- Don't use long-term keys not in the KDB.
- Don't issue tickets with a session key not supported by the client,
  or not in the list of enctypes the service is known to support.

Policy about what service key enctypes should be accepted by a service are 
implicit in the set of keys the service has.  This applies even when the 
service is the TGS, though in several implementations the TGS actually uses 
the KDB as its key store, so something extra is required if one wants the 
set of keys available to TGS-as-service to be different from the set 
available to the KDC.

> think you'll need configuration, or better, obsolescence, to get rid of

The point of a prohibited-enctypes policy is to disable use of enctypes 
that are considered so weak that accepting them would compromise security. 
Of course, prohibiting use of an enctype in this way will cause operational 
problems if it has not first been removed from use.  But as you note, that 
takes actual work, at least some of which is outside the scope of this 
discussion.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 10 Nov 2009 09:32:58 -0800

> exchanges, not during key maintenance.

If you're arguing that when a user sets a new password/key the main DB  
should store not-to-be-used enctypes for it, then I don't agree.  For  
one thing, I don't see the advantage, and for another it seems like a  
really obvious way to guarantee there can't be code paths that might  
expose a weakness.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 11:38:41 -0600

> really obvious way to guarantee there can't be code paths that might  

I'm arguing against a separate knob for "what enctypes to create keys
for".  I'm certainly happy with a "don't ever use these enctypes" knob
causing keys of those enctypes to never be created.

Also, it's important for services to tell the KDC what enctypes they
support, either via what keys they have enctypes for (the MIT way) or
separately.  And it's important for user password-derived keys to be
derived by a realm service, because the enctypes supported by a client
might not be all the enctypes that the user needs keys for.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Nov 2009 13:14:16 -0500

--On Tuesday, November 10, 2009 11:38:41 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

> for".

As an operator, any KDC implementation I deploy will have that knob.  I'm 
not convinced it necessarily needs to be represented in the kDC data model, 
but it definitely needs to exist.

> might not be all the enctypes that the user needs keys for.

Agree with both of these points.  The former pretty much requires 
representation in the KDC data model.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 12:17:16 -0600

> but it definitely needs to exist.

If it needs to exist then it should be in the model.

IMO one can do without it.  It does no harm, however, to have it.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Nov 2009 13:37:46 -0500

--On Tuesday, November 10, 2009 12:17:16 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> As an operator, any KDC implementation I deploy will have that knob.
>> I'm  not convinced it necessarily needs to be represented in the kDC
>> data model,  but it definitely needs to exist.
>

Does it?  Is it data or configuration?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 12:46:14 -0600

> IMO one can do without it.  It does no harm, however, to have it.

Let me re-state my case: enctype policy management needs to be _simple_.
The set of enctype policy knobs in MIT krb5 is not exactly sysadmin-
friendly.  Let's not make the same mistakes now.

The bare minimum enctype policy management knob set needs to be
identified, and those knobs must be REQUIRED.  All other knobs may be
OPTIONAL, RECOMMENDED, or REQUIRED to implement, for all I care, but we
must give guidance on how to use the minimal knob set to get the desired
effect (namely, to constrain what enctypes are used).

The minimal set of enctype policy knobs, IMO, is this:

 - What enctypes will be accepted or attempted.  This covers:

    - Authenticator encryption enctype
    - Authenticator sub-session key enctypes
    - Ticket enc-part encryption key enctype (in AP-REQs and in
      additional-tickets field in KDC-REQ-BODY)
    - etype field from KDC-REQ-BODY
    - enc-authorization-data encryption key enctype

   This is a knob that should be supported on:

    - KDCs
    - services
    - clients

   and which applies even to the Kerberos V5 GSS-API mechanism.

   Default value: the set of all enc-types excluding 1DES enctypes.
   Alternative default value: AES enc-types only.

 - What enctypes will be excluded from all other enctype lists
   unconditionally (no mater what their given values).  (i.e., a weak
   enctype exclusion knob.)

   This knob too should be available on KDCs, clients and servers.

   Default value: either empty, or, if we're ready to obsolete the 1DES
   enctypes, the set of 1DES enctypes.

and, maybe, this:

 - What enctypes can be tried / will be accepted for bare (not FAST-
   protected) PA-ENC-TIMESTAMP.  If not set then the previous knob
   provides a default.

   This knob is needed only on KDCs and clients.

   Default value: same as previous knob.

So, two or three in the minimal enctype policy knobs set.

If in addition to this you want knobs for specifying what enctypes
long-term keys can be created for, that's fine.  (Such a knob is needed
only on password/key change services.)

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Nov 2009 14:12:12 -0500

> friendly.  Let's not make the same mistakes now.

Agreed.  What I'm telling you is that as an operator, what I actually _use_ 
in a production realm is the ability to control what enctypes are used when 
keying principals (primarily so I can install software that supports a new 
enctype but not phase use of it in until I choose) and the ability to 
disallow the use of existing enctypes even when keys exist.  In addition, I 
expect eventually to use a per-principal knob allowing me to restrict, for 
a small set of services, what enctypes are used when those services are 
rekeyed.  I do this because I do not want the KDC to issue tickets with AES 
keys to a service that does not support AES, and we have several of those.

>    Alternative default value: AES enc-types only.

IMHO the correct default here is to use any and all enctypes the software 
supports, minus those in the unconditional-exclude list, and let 
negotiation take care of the rest.  This gets you maximum interoperability 
while allowing any party to declare a particular enctype too weak to use.

I don't believe the third knob you describe is in the minimal set.

In addition to the policy knobs you describe, the KDC must know what 
enctypes are actually supported by a service, since it must issue tickets 
which use an enctype the service can support.  Traditionally this has been 
implied by the list of long-term keys the KDC has for that service, but 
today, there are common implementations/deployments in which services have 
passwords, not keys, and the KDC can derive a key for a service for any 
supporte enctype on demand.

> only on password/key change services.)

Yes, that is needed only on services that key principals.  It is arguably 
part of the configuration of such a service, rather than part of the KDC 
data described by the model.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 13:58:43 -0600

> enctype but not phase use of it in until I choose) and the ability to 

That's not like the supported_enctypes option of the MIT kadmind, but
like the -e argument to the MIT kadmin commands + the permitted_enctypes
option to the MIT software on the KDC.

> keys to a service that does not support AES, and we have several of those.

Indeed, that is a highly desirable goal, but the set of enctypes
supported by some service is known by that service, not by the KDC, and
whatever you may store in the KDB about it can get out of dat when you
upgrade the service's software.

> >   [...]

Ah, yes, I'd meant to say that, but the way I edited my message I forgot
to.

> I don't believe the third knob you describe is in the minimal set.

I'd be OK with it in that set though.

> supporte enctype on demand.

Yes.

> data described by the model.

Indeed, that is what I wrote.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Nov 2009 20:30:48 -0500

I'm still not convinced that all this complexity is entirely needed.
Remember that 6.1.1.13 provides an escape to a policy object.  I'd
like to look into the option of specifying something incredibly simple
for the info model, with the understanding that anything more complex
will be part of the policy system.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Nov 2009 19:27:49 -0600

> will be part of the policy system.

One or two global enctype lists seems simple enough.  One enctype list
if we allow negation, else two.
_______________________________________________
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 05:47:12 +0100

> change at different times.

I believe that we're approaching the policy object event horizon here
and I think we should stick with the basic principle wrt policy in
this spec which has been that its either really really simple or its
arbitrarily complex and is a "policy object".

Please review and commend Sams and my suggestion from yesterday!

	Cheers Leif

---

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

> arbitrarily complex and is a "policy object".

I would like to see clarification of how we draw the line between what
should be an attribute and what should be a policy object.  I think
that some aspects of controlling key selection, particularly session
key selection, during ticket issuance are basic enough to not be
counted as policy objects.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Nov 2009 01:42:51 -0500

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> I would like to see clarification of how we draw the line
    Tom> between what should be an attribute and what should be a
    Tom> policy object.  I think that some aspects of controlling key
    Tom> selection, particularly session key selection, during ticket
    Tom> issuance are basic enough to not be counted as policy
    Tom> objects.

Can you give examples here?  The only thing I can think of that falls
into this category is the set of enctypes the KDC assumes the server
supports.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg