On Thu, 14 Feb 2013, Andrew Deason wrote:
On Thu, 14 Feb 2013 23:00:24 +0000
Simon Wilkinson <[email protected]> wrote:
Implementing this would be tricky. You'd have to require that both
keys were present in the same keytab, and then have
gss_accept_sec_context accept any credential, and then export the
accepted name and check that it matched either of the keys that you
were prepared to accept. Doing that in a way that is mechanism
independent isn't possible with stock GSSAPI (we hit this problem with
OpenSSH). Doing it in a mechanism specific fashion requires all sorts
of nastiness around gss_export_name.
The above seems to imply that the server needs to be able to accept
either one all the time, if I'm reading that correctly. That's not what
I mean. My thinking was that servers with the cell-wide key would just
use afs-rxgk@_afs.cell, and servers that don't have the cell-wide key
would use afs3-bos@host. The client would try with afs3-bos@host, but if
that doesn't exist (or the connection negotiation fails), we would retry
assuming that we can use afs-rxgk@_afs.cell. That's a problem?
I was also thinking that the server would only have one identity, and the
client would try one and fall back to the other if the first one failed
(when I was thinking about using the cell-wide identity for db machine
bosservers). The bosserver is really functioning more like cron or an
init system (i.e., local to a machine) than a cell-wide service, though.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
