On Fri, 2014-06-20 at 14:30 -0400, Nathaniel McCallum wrote: > On Fri, 2014-06-20 at 14:10 -0400, Simo Sorce wrote: > > 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 :-) > > Ah, right. This boils down to the KDC not having any way to know what > enctypes the destination principal supports. Thanks for clarifying that. > > In this case, the ASN.1 provided is confusing. I think something like > this would be clearer and less error prone: > > KeytabGetMessage ::= CHOICE { > fetch [0] Fetch, > create [1] Create > reply [2] Reply > } > > Fetch ::= SEQUENCE { > serviceIdentity [0] OCTET STRING > } > > Create ::= SEQUENCE { > serviceIdentity [0] OCTET STRING, > enctypes [1] SEQUENCE OF Int16, > password [2] OCTET STRING OPTIONAL > } > > This would also, I think, result in a cleaner implementation where the > type of operation is logically built into the decoding step.
Well yes this looks better, but honestly, I think it is a bit late for this kind of feedback, given I have a working patchset, and asked months ago if people wanted to review the logical design. How strongly do you feel we absolutely need to change this and go through a new review cycle ? Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
