RE: [P2PSIP] Re: HIP pros and cons

Perhaps we store the CRL in the DHT.

The problem you want to protect against is amenable to a non-real time CRL
update mechanism, which is a solvable problem.  If you wanted a near-instant
revocation, then you need a real time access to an up to date CRL.

Brian

> -----Original Message-----
> From: David Barrett [mailto:dbarrett@quinthar.com]
> Sent: Tuesday, December 18, 2007 4:35 PM
> To: 'Ali Fessi'
> Cc: p2psip@ietf.org
> Subject: RE: [P2PSIP] Re: HIP pros and cons
> 
> And if I check the "save my password" checkbox that every client will
> naturally provide?  Then my identity is lost forever?
> 
> One mitigation would be to make the certificates very short-lived: say,
> daily.  Then if I lose my laptop, then a hacker can impersonate me for the
> rest of the day.  (Though if AT&T took 24 hours to turn off your cell
> phone
> I'm not sure people would be satisfied by that.)
> 
> However, then that means we need to re-enroll daily, and it's not really
> an
> "enrollment" server but rather a "reserve your name on the system for a
> day"
> server.
> 
> To which we might add some sort of long-lived credentials on the
> enrollment
> server so -- if I forget to log on one day -- somebody can't hijack my
> name.
> 
> Then it becomes a full-fledged authenticate/authorize/enroll server that
> we
> need to check daily.
> 
> Regardless, it still sounds an awful lot like a central authentication
> server that needs to be consulted at the start of each session (and
> periodically thereafter) to get onto the network.
> 
> I don't think this is bad.  I just think it's unavoidable.
> 
> -david
> 
> > -----Original Message-----
> > From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de]
> > Sent: Tuesday, December 18, 2007 1:13 PM
> > To: David Barrett
> > Cc: p2psip@ietf.org
> > Subject: Re: [P2PSIP] Re: HIP pros and cons
> >
> > Hi David,
> >
> > David Barrett wrote:
> > > Just curious, if my laptop gets stolen, will P2PSIP provide any
> facility
> > for
> > > me to prevent the thief from making and receiving calls in my name?
> >
> > Once you have a certificate that you have received from the enrollment
> > server, you can protect the private key that belongs to the certificate
> > with a password on your local machine.
> >
> > So nobody will be able to steal your identity (well, except with a
> > dictionary attack on your password).
> >
> > You don't need to contact one of the login servers here, except for
> > verifying whether a peer certificate is in the revocation list.
> > Certificate revocation is indeed a problem.
> >
> >
> > Cheers,
> >   Ali
> >
> > > If so, how will that be done without a 24/7 realtime check to either a
> > > centralized or federated server?
> > > If we assume there's some kind of password, then that means there's
> some
> > > sort of password check.  If we assume we can ban clients, then we need
> > to
> > > somehow record which clients are banned and check that.  If we can
> > revoke
> > > certificates, then there's a certificate revocation list.
> > >
> > > Is there any way to support this seemingly obvious requirement -- the
> > > requirement that I can prevent a thief from forever, undetectably
> > > impersonating me -- without some sort of central, realtime, 24/7
> lookup?
> > >
> > > Or is the answer "to be determined" or "not our problem; we punt this
> to
> > > another layer"?
> > >
> > > -david
> 
> 
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip