The trouble with all this is: how can VeriSign (or any other CA) verify individuals' IDs? How can VeriSign (or any other CA) verify a corporation's officers' IDs?
The answer: they can't do as good a job as government agencies can.
Governments make ideal CAs: they issue birth certificates, drivers licenses, passports and they are, or tend to be distributed. I.e., different govt agencies issue different ID docs and can verify each other's documents, usually by requiring people to submit multiple IDs from different sources -- the idea being that to fake your ID you must fake ID documents from multiple agencies, a task that is, hopefully difficult.
Ultimately you can only approach 100% certainty of a person's ID, and the best way to do it is by requiring and reviewing multiple claims of ID from different sources. A birth certificate can be validated by contacting the issuing authority. A driver's license can be validated by checking the picture on it and then checking the license's validity with the license's issuer. Hopefully the issuers are well-known and hopefully the communications with them are somewhat secure (circularity rears its head). And so on.
In fact, DMVs (Dept. of Motor Vehicles) in the States (ok, New York's at least) have ID point systems whereby they assign different point totals to different kinds of IDs and require that you submit enough IDs to add up to a minimum ID point total in order to establish your ID to them. I think the U.S. Post Office does the same sort of thing for passport applications.
So, IMHO, government agencies would make very good CAs. At least they should sell ID verification services to third party CAs (in a way they already do: notarys public can attest to an individual's ID and the notarys can be verified with the state and can be contacted by the CAs to verify their IDs).
Of course, it would be nice if there were a smartcard standard that all citizens (of a country or of any country) could use and to which their governments could download certificates....
But hey, even then, certificates can be stolen; passwords can be stolen; fingers can be cut off; people can be coerced into providing their biometrics ("stand in front of that retina scanner and act normal"); OS security can be broken and CA public keys modified/added.
Sun's current SecureNFS system, no longer based strictly on NIS+, is available for Solaris 2.6, 7 and 8. It's called SEAM and it works by adding a new RPC auth flavor called RPCSEC_GSS based on an earlier flavor by MIT called AUTH_GSSAPI.
This means you can use GSS-API to authenticate/secure NFS, which means you can use Kerberos V (Sun also includes GSS-API plug-in mechanisms for doing Diffie-Hellman, ala NIS+).
Sun has opened source for this under the OS-friendly SISSL (not SCSL).
Meantime, the University of Michigan is doing an NFSv4 implementation for Linux and they already have completed their own implementation of RPC with RPCSEC_GSS (which they have released).
Surely the Michigan code will be adapted to the existing NFSv3 code in Linux.
The RPCSEC_GSS flavor can be used with NFSv2, NFSv3 and NFSv4 (the latter is not yet a standard).
You just need to keep NTLM passwords in AD. Windows 2000 makes the synchronization of NTLM and Kerberos passwords trivial, from the user's perspective.
You ALSO need to allow anonymous LDAP/SAM lookup access in AD. This can be done on a per-container and per-object basis if you wish.
The general rule is: if you must run Windows 2000 clients and services with Kerberos authentication then your KDCs had better AD.
The whole [technical] point of Microsoft's profile-in-Kerberos tickets extension is to allow them to deny anonymous lookups. This is because the servers you connect to won't need to lookup your user profile data if it's provided in the Kerberos ticket.
Of course, MS's extension stinks for a number of reasons.
I suggest you search the krb-protocol
and ietf-krb-wg mailing list archives. (Most posters cross-post to both lists. I don't know where there might be archives for the IETF list).
There was a thread in those lists, earlier this summer, about this whole issue.
My opinion is that MS is right to want to make it possible to deny anonymous lookups that previously had to be allowed. I think they're approach is wrong. I have proposed more than one alternative on the krb-protocol list.
Unfortunately, there is much too much interest in whining about MS' extension and not enough interest in putting forward a better alternative. Yes, MS is abusing the good will of those who dreamed up and made Kerberos possible; I know. I hope we don't degenerate into yet another debate about MS/antitrust/etc.
Another problem is that there is a strong aversion to mixing any authorization features with an authentication protocol. This is quite understandable, though I submit that with SSO systems there is an authorization issue: how to, practically, control delegation of impersonation OR, in other words, how do you authorize remote services to act on your behalf to other services while not giving those services the rights to impersonate you completely.
Slashdot Mirror
The answer: they can't do as good a job as government agencies can.
Governments make ideal CAs: they issue birth certificates, drivers licenses, passports and they are, or tend to be distributed. I.e., different govt agencies issue different ID docs and can verify each other's documents, usually by requiring people to submit multiple IDs from different sources -- the idea being that to fake your ID you must fake ID documents from multiple agencies, a task that is, hopefully difficult.
Ultimately you can only approach 100% certainty of a person's ID, and the best way to do it is by requiring and reviewing multiple claims of ID from different sources. A birth certificate can be validated by contacting the issuing authority. A driver's license can be validated by checking the picture on it and then checking the license's validity with the license's issuer. Hopefully the issuers are well-known and hopefully the communications with them are somewhat secure (circularity rears its head). And so on.
In fact, DMVs (Dept. of Motor Vehicles) in the States (ok, New York's at least) have ID point systems whereby they assign different point totals to different kinds of IDs and require that you submit enough IDs to add up to a minimum ID point total in order to establish your ID to them. I think the U.S. Post Office does the same sort of thing for passport applications.
So, IMHO, government agencies would make very good CAs. At least they should sell ID verification services to third party CAs (in a way they already do: notarys public can attest to an individual's ID and the notarys can be verified with the state and can be contacted by the CAs to verify their IDs).
Of course, it would be nice if there were a smartcard standard that all citizens (of a country or of any country) could use and to which their governments could download certificates....
But hey, even then, certificates can be stolen; passwords can be stolen; fingers can be cut off; people can be coerced into providing their biometrics ("stand in front of that retina scanner and act normal"); OS security can be broken and CA public keys modified/added.
Oh well...
This means you can use GSS-API to authenticate/secure NFS, which means you can use Kerberos V (Sun also includes GSS-API plug-in mechanisms for doing Diffie-Hellman, ala NIS+).
Sun has opened source for this under the OS-friendly SISSL (not SCSL).
Meantime, the University of Michigan is doing an NFSv4 implementation for Linux and they already have completed their own implementation of RPC with RPCSEC_GSS (which they have released).
Surely the Michigan code will be adapted to the existing NFSv3 code in Linux.
The RPCSEC_GSS flavor can be used with NFSv2, NFSv3 and NFSv4 (the latter is not yet a standard).
Good luck!
You ALSO need to allow anonymous LDAP/SAM lookup access in AD. This can be done on a per-container and per-object basis if you wish.
The general rule is: if you must run Windows 2000 clients and services with Kerberos authentication then your KDCs had better AD.
The whole [technical] point of Microsoft's profile-in-Kerberos tickets extension is to allow them to deny anonymous lookups. This is because the servers you connect to won't need to lookup your user profile data if it's provided in the Kerberos ticket.
Of course, MS's extension stinks for a number of reasons.
I suggest you search the krb-protocol and ietf-krb-wg mailing list archives. (Most posters cross-post to both lists. I don't know where there might be archives for the IETF list).
There was a thread in those lists, earlier this summer, about this whole issue.
My opinion is that MS is right to want to make it possible to deny anonymous lookups that previously had to be allowed. I think they're approach is wrong. I have proposed more than one alternative on the krb-protocol list.
Unfortunately, there is much too much interest in whining about MS' extension and not enough interest in putting forward a better alternative. Yes, MS is abusing the good will of those who dreamed up and made Kerberos possible; I know. I hope we don't degenerate into yet another debate about MS/antitrust/etc.
Another problem is that there is a strong aversion to mixing any authorization features with an authentication protocol. This is quite understandable, though I submit that with SSO systems there is an authorization issue: how to, practically, control delegation of impersonation OR, in other words, how do you authorize remote services to act on your behalf to other services while not giving those services the rights to impersonate you completely.
Nick