Windows Live vs Kerberos - Kerberos

This is a discussion on Windows Live vs Kerberos - Kerberos ; Hi. I am doing a report on Web authentication and have come over the Windows Live login-service, which basically is a PKI (public key infrastructure) where live.com acts as the KDC (Key Distribution Center). Can someone tell me differences between ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Windows Live vs Kerberos

  1. Windows Live vs Kerberos

    Hi.
    I am doing a report on Web authentication and have come over the
    Windows Live login-service, which basically is a PKI (public key
    infrastructure) where live.com acts as the KDC (Key Distribution
    Center).

    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).

    Looking forward to your answers!


  2. Re: Windows Live vs Kerberos

    royend 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

  3. Re: Windows Live vs Kerberos

    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/pk...ki_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 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@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >


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

  4. Re: Windows Live vs Kerberos

    Frank Siebenlist writes:
    > 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/pk...ki_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 ;-)


    re:
    http://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos

    one of the issues with x.509 identity (public) digital certificates from
    the early 90s was "what might the necessary and sufficient information
    be required in the digital certificates" (for possibly accepting relying
    parties). as a result there was some direction to include more and more
    personal information ... to cover the possible requirements of any
    relying parties which might be depending on the (public) digital
    certificates (PKI somewhat assumed that public digital certificates were
    being sprayed all over the world).

    however, by the mid-90s, several organizations were starting to realize
    that x.509 identity (public) digital certificate, increasing overloaded
    with personal information represented significant liability and privacy
    issues. some of these organizations, attempting to salvage something of
    the digital certificate infrastructure, regressed to something called
    relying-party-only digital certificates
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    where the individual information was restricted to some sort of account
    number (or record locator) and a public key. The account/record allowed
    the personal information to be removed from public distribution. The
    issue then was that it could be trivially shown that the actual digital
    certificates were redundant and superfluous ... since the account/record
    would (or tirivially could) typically also include the public key
    (effectively regressing to the original pkinit scenario).

    The trade-off (from the digital certificate design point adapted from
    the letters of credit/introduction from sailing ship days) ... was that
    it was necessary to include all the required information needed by
    relying party in the document. Once the pertinent information moved some
    place else ... then the original purpose for such documents (or digital
    certificate) became redundant and superfluous.

    There were some additional issues with various of the relying-party-only
    certificates ... besides becoming redundant and superfluous. Even with
    relying-party-only digital certificates eliminated all the individual
    specific information except record-locator/account-record and public key
    .... they could still be quite enormous and require significant
    processing overhead. This was especially apparent in payment
    transactions ... where the overhead of a relying-party-only digital
    certificates could represent an 100-fold payload size increase
    http://www.garlic.com/~lynn/subpubkey.html#bloat

    that issue was so significant (in payment infrastructure) that the x9
    financial standards body started a work item for "compressed" digital
    certificates ... with objective of attempting to reduce the payload
    bloat increase to possibly only 5-fold (again for something effectively
    redundant and superfluous).

+ Reply to Thread