Ahhh, pkinit history... actually, pkinit originates from the good old DCE efforts at OSF from the 90's.
The DCE-RFC's 68.3/4 show the evolution that Lynn talked about, where the last 68.4 was used for the current IETF pkinit incarnation after some heated ietf-workgroup sessions... http://www.opengroup.org/dce/tech/pki/dce_pki_spec_08.pdf The first versions of pkinit were purely key-based, essentially like ssh, where the public key was matched to a Kerberos principal. At that time we thought that X509-PKIX-PKI was going to take over the world and X509 certs were the future... (I'm sure that Lynn has a few references about those dreams ;-) ), so we introduced X509-cert-based authentication for DCE/Kerberos in RFC 68.4, where the identity management was taken over by the PKI, and Kerberos (ideally) didn't need any user-database and would issue tickets to whoever would authenticate with a x509-cert and the principal name would be derived from the subject's DN. As mentioned, there were some heated arguments in the ietf working group - the idea that it would demote Kerberos to a credential translation service and would take away the identity management part was probably one reason... In retrospect, I'm not sure if we made any real improvement with the changes in the pkinit model... maybe we should have listened better to Carl Ellison and Lynn ;-) Regards, Frank. Anne & Lynn Wheeler wrote: > royend <[EMAIL PROTECTED]> writes: >> Can someone tell me differences between Windows Live and Kerberos? >> Is it possible for instance to sat that Windows Live uses as its basis >> the Needham-Schroeder protocol, the same way as Kerberos does? >> >> I believe that Kerberos is a more general protocol which is used in >> network authentication, as Windows Live is a special service for web >> sites, gathering all users at a single sign on (SSO). > > how 'bout ... > http://en.wikipedia.org/wiki/Windows_Live_ID > > for a little drift ... original kerberos was done with shared > secret/password for user authentication. once that is done, > then kerberos tickets can be passed around between a lot of > applications as a sso mechanism. > > m'soft contracted with an outside corporation to do a kerberos > impelementation for windows ... making it the basis for windows > authentication. about the same time that was going on there was a > ietf/internet draft written called pk-init for kerberos. > > in the original pk-init, the registration of password was replaced with > the registration of public keys ... and in place of entering a password, > the user generated a digital signature (with their corresponding private > key). this was not a PKI implementation which requires something called > digital certificates ... which were nominally invented to provide some > trusted information about total strangers during first time > communication ... aka in the original PKI design point, a total > stranger, that is otherwise not known to the organization and/or for > which there has never been any prior contact ... can present a digital > certificate and be granted access to systems (purely based on the > information contained in the digital certificate). in that sense, > digital certificates can be considered sort of a very long lived > "tickets" ... where all the authorization information is visible/public > and targeted at being used by strangers in first time communication (the > letters of credit/introducation scenario from sailing ship days, where > relying parties had no other recourse to information for first time > interaction with total strangers) > > There was then some amount of lobbying that the pk-init drift should > support both digital signature based authentication involving known > individuals (i.e. the original public key registration scenario) as well > as the PKI-scenario with digital certificates (supposedly to allow total > strangers with no prior contact and/or authorization, access to > systems). > > misc. past posts mentioning kerberos and/or pk-init > http://www.garlic.com/~lynn/subpubkey.html#keberos > > in the early 80s, we were periodically involved dropping by project > athena and reviewing various projects, including kerberos. we happened > to be there a week when the original cross-domain kerberos process was > being worked out. more recently, we sat thru a vendors description of > their SAML implementation for cross-domain authentication. While the > format of SAML messages and kerberos tickets are different, the > description of the flows were identical. > > corresponding kerberos wiki page > http://en.wikipedia.org/wiki/Kerberos_(protocol) > > from my rfc index > http://www.garlic.com/~lynn/rfcietff.htm > > and click on "Term (term->RFC#)" in the "RFCs listed by" section > > and then scroll down to kerberos, i.e. > > kerberos > see also authentication , generic security service , security > 5021 4757 4752 4559 4557 4556 4537 4430 4402 4121 4120 3962 3961 3244 > 3129 2942 2712 2623 1964 1510 1411 > > clicking on the RFC numbers, brings up the corresponding summary > in the lower frame, for instance: > > 4757 I > The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows, > Brezak J., Jaganathan K., Zhu L., 2006/12/11 (18pp) (.txt=36562) (Refs > 1320, 1321, 1964, 2104, 3961, 3962, 4120, 4537) > > clicking on the ".txt=nnnn" field, fetches the actual RFC > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > -- Frank Siebenlist [EMAIL PROTECTED] The Globus Alliance - Argonne National Laboratory ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
