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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
