[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