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