[Freeipa-devel] Design Review Keytab Retrieval

[Simo Sorce]

On Fri, 2014-06-20 at 14:05 -0400, Nathaniel McCallum wrote:
> On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote:
> > Although the code is all done it would be nice to have a review of the
> > feature, to see if it has all been captured:
> > http://www.freeipa.org/page/V4/Keytab_Retrieval
> 
> I'm a bit confused about the behavior of enctypes in the Request.
> 
> "A list of enctypes is always necessary in input when a new keytab is
> requested. However the list is filtered though the allowable enctypes
> list and if nothing is left the operation is refused."
> 
> +1. However, the generated keys should be the set of allowed enctypes,
> not the intersection between allowed and requested enctypes. This would
> permit the later requesting of enctypes that were allowed at the time of
> creation, but not requested.

Which you absolutely do not want.
If your service understands only RC4-HMAC and you provide it with AES
keys then communication from a third party client will fail because the
KDC will give that client an AES encrypted ticket that the service does
not know how to decrypt.

This is particularly important for old NFS Servers (like RHEL5) that
understand only DES (sigh!)

> "If the getNew attribute is false, then the existing key is being
> requested. In this case password and enctypes MUST NOT be set."
> 
> I don't get this. Shouldn't the return value of this request include
> only the intersection between allowed and requested enctypes?

Not when you are retrieving existing keys. Only when you are creating
new keys.

> There is no point in responding with enctypes the client has not requested.
> And indeed, this provides extra data points to attack.

??

> Having this proposed behavior also means you can remove OPTIONAL from
> enctypes.

OPTIONAL is there because when you request existing keys it makes no
sense to send a lit of enctypes, you get what the KDC has, the whole
package, because you must be able to decrypt any ticket you get, getting
a subset of keys would make no sense.

> So as it stands, enctypes currently controls what keys are generated. I
> would prefer that enctypes controls what keys are returned. Am I missing
> something?

I most definitely think you are :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York