It seems that in the current service-cert authz processing in our C
code, there is a potential exposure:
if you have multiple services and associated certs, like
[EMAIL PROTECTED],edu, [EMAIL PROTECTED],edu and [EMAIL PROTECTED],edu, then the client
could be duped in expecting a [EMAIL PROTECTED], but approving a
[EMAIL PROTECTED],edu. This could be an issue if you have multiple accounts
that run different services of different sensitivity, then
compromising a low-sensitivity account could be used to dupe a client
in thinking that she talks to a highly trusted service.
This doesn't seem a very likely compromise, and I see it as more
"second order" and certainly less sensitive than our current default
host authz processing, but it would be good to migrate to a more
strict policy enforcement that would not allow this.
Note that we have the issue of backwards compatibility with C clients
that rely on this loose association of host and service certs, and
would break if we enforce a stricter policy, like our CAS-C-clients.
By making the stricter policy an option and making the current service-
cert processing the default for the next GT release, and subsequently
deprecating the looser processing in the release after, we could
migrate relatively painlessly to a better world ;-)
Securely yours, Frank.
On Nov 18, 2008, at 9:23 AM, Rachana Ananthakrishnan wrote:
Currently GSI C and GSI Java process host and service certificates
differently.
In GSI C, [EMAIL PROTECTED] and [EMAIL PROTECTED] are treated as equal.
That is,
the string prior to @ is ignored and if the hostname matches, the
GSS Names
are treated as equal. So all service certificates and host
certificate for a
given host will match.
In GSI Java, the strings prior to @ are also expected to match. If no
service piece is specified, then host is assumed. That is
[EMAIL PROTECTED]
matches hostname, but not [EMAIL PROTECTED]
Is there some specification that covers the expected behavior?
I see merit to [EMAIL PROTECTED] not matching [EMAIL PROTECTED], and
keeping the
GSI Java behavior. The host certificates are typically maintained
and stored
in privilege account, and the service certificate allows for a
client to do
"automated" authorization with just the service name.
But we would like to hear if there are groups that leverage the GSI C
behavior and any thoughts on what we want as default for both
implementations.
Thanks,
Rachana
