[AFS3-std] rxgk/rxgk-afs updates
Benjamin Kaduk
kaduk@MIT.EDU
Wed, 6 Mar 2013 16:24:00 -0500 (EST)
On Tue, 5 Mar 2013, Benjamin Kaduk wrote:
> I'll make the indicated changes in the next day or two (destructively
> rebasing as needed).
Updated:
GSS negotiation loop description. Still not great, but should be more
correct.
Moved db/fileserver specificity to the introduction of rxgk-afs, reverting
the previous commit entirely (including the bit wherein
non-db,non-fileserver negotiation services MAY use the cell-wide key and
the authenticator appdata blob).
I took your changes to the VL_RegisterAddrsAndKey description (with my
mentioned modification).
> On Tue, 5 Mar 2013, Simon Wilkinson wrote:
>
>>
>>> commit db73249fa194cb05dccd2de9a8e97794592e9cc5
>>> Talk about acceptor principal names for GSSNegotiate
>>
>> I'm happy with the client side language, but...
>>
>> + The server's configuration as a GSS acceptor SHOULD NOT specify
>> + a principal name for acceptor credentials, allowing the use of any
>> + available credentials for the negotiation service.</t>
>>
>> I strongly disagree here. The server should specify the identity which it
>> is accepting. There have been numerous cross-service attacks in the past
>> where flaws in service A can be used to compromise service B because they
>> are both prepared to accept the same keys (not least, the original GSS ssh
>> work). I would rather that we didn't end up being service A or service B -
>> so I think the SHOULD NOT here is entirely inappropriate.
>
> This text was based on a conversation with jhutz to the effect that "servers
> should be liberal in what they accept", but I am not tightly wedded to it.
> If the client needs application-specific knowledge to choose a target
> principal name, then requiring that same application-specific knowledge in
> the server hardly seems an overbearing burden.
>
> Do you want to just remove the text entirely, or change it to a SHOULD
> specify the name, or something else?
Still awaiting input here.
-Ben