[p2p-sip] Fwd: what's wrong with DNS?

[slavitch at gmail.com (Michael Slavitch)]

User auth is cached locally on a PC , and can be cached for a long time
without access to the DC, the ticket duration can be tuned.  On connection
to the DC via a VPN or local connection the ticket is refreshed, which
allows a single user login session to be indefinitely long, which is why
login scripts fail for many users: they log in once per reboot.

>From a user perspective they logged in once many months ago with sessions
that are stored via hibernation.

For service tickets, the valid range is from 0 to 99,999 minutes. For user
tickets, the valid range is from 0 to 99,999 hours. A value of zero
effectively turns off expiration. Any other value sets a specific ticket
lifetime. Under the hood tickets get renewed, DC's get contacted, but only
once in a while.  A roaming user can be away for months without a DC
login.

A ticket value of zero is the common ticket length for road warriors for
just this purpose.

The same can be true for P2PSIP of course,  the tickets can be renewed on
contact with supernodes, which are identical to domain controllers at the
data level, with the provisio that their databases are cached.

A domain controller is nothing but a DHT with a hash ratio of 100%, a full
table.

In fact, in my analysis, ongoing moves and changes that are inherent in
Domain Controllers reduce the hash value to 98-99%.  In effect Active
Directory is already a DHT, and a good proof of viability.

Regards

M

On 11/28/06, Sean Olson <seanol at exchange.microsoft.com> wrote:
> A key difference with domain auth is that you do need access to the DC for
most auth needs. Kerb tickets last hours not months. Cert based auth can
give you those longer durations at a cost. We've also implemented other auth
techniques with P2P in Vista.
>
> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu [mailto:
p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
> Sent: Tuesday, November 28, 2006 9:53 AM
> To: Brian Rosen
> Cc: p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Fwd: what's wrong with DNS?
>
> Anyone using a Windows notebook that authenticates to a domain is
> using this technology right now.  This is not open research.
>
> On 11/28/06, Brian Rosen <br at brianrosen.net> wrote:
> >
> > I think you are confusing a credential validation from a credential
> > issuance.
> >
> > I think what you have in mind is that you get a credential that changes
> > every few months: it's the password you use to authenticate.  That
> > credential is validated every time you boot.
> >
> > The plan I think most of us have in mind is that you get a credential,
> > perhaps something like an x.509 cert, good for a couple of months or
years,
> > that is validated every time you boot (e.g. connect to the overlay).
> >
> > The difference is you want a centralized service to do the
authentication,
> > and we want a p2p distributed service.
> >
> > Then, you want a centralized authorization service, where we think the
DHT
> > provides that also as a p2p distributed service.
> >
> > Are there other people on the list who think what Frank is advocating is
a
> > good idea?
> >
> > Brian
> >
> >
> > > -----Original Message-----
> > > From: Frank W. Miller [mailto:fwmiller at cornfed.com]
> > > Sent: Tuesday, November 28, 2006 11:33 AM
> > > To: Brian Rosen
> > > Cc: 'Eunsoo Shim'; p2p-sip at cs.columbia.edu
> > > Subject: RE: [p2p-sip] Fwd: what's wrong with DNS?
> > >
> > > On Tue, 2006-11-28 at 10:56 -0500, Brian Rosen wrote:
> > > > You understand that you are proposing a centralized service that
> > > > authenticates you every time you boot, and a centralized
authorization
> > > > service that authorizes you AT CALL TIME, at least the first time
per
> > > boot?
> > > >
> > >
> > > Not exactly.  Authorization happens at boot, i.e when your client
starts
> > > up.  Authentication happens at the first interaction between two UAs.
> > >
> > >
> > > > The direction we are going is that you use the centralized
credentialing
> > > > service to get credentials effectively once in a lifetime of the
> > > credential,
> > > > which might last at least months, and maybe years.  Thereafter, the
> > > > distributed hash table takes care of authentication and
authorization
> > > peer
> > > > to peer without any central service.
> > > >
> > >
> > > Understood.  I question the practicality of this for at least a couple
> > > of reasons.
> > >
> > > First, my view is that credentials should be changed
periodically.  The
> > > longer a credential is available, the more likely it is that it can be
> > > hacked.
> > >
> > > Second, the only real difference is how often the credentials are
issued
> > > and checked.  The DHT approach would do it "once" for all time, my
> > > proposal does it "once" at client boot time and at the beginning of a
> > > UA->UA interaction.  The need or lack of need for a centralized
> > > authority does not go away because of the use of a DHT to lengthen the
> > > time that credentials are valid.
> > >
> > >
> > > > I would definitely not call what you are proposing a peer to peer
> > > service;
> > > > it relies on centralized authentication and centralized
authorization
> > > > services in real time.
> > > >
> > >
> > > Well, its P2P except for initial authorization and subsequent initial
> > > authentications.
> > >
> > >
> > > FM
> > >
> >
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061128/7b73de0f/attachment.html