Windows Live vs Kerberos

[Frank Siebenlist]

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 <royend at gmail.com> 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           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory