[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Son-of-IKE Selection Criteria?

Steve,

	The problem here is that your risk model is still broken, you are
assuming a risk that already means you have lost.

	If you can't trust your ISP to conceal your trafic then your trafic
is already compromised.

	
	Using JFK as presently configured I can still trace the packets back
to Steve Bellovin in your scenario:

1) I look at the IP header source address
2) I find the ISP who owns the source address 
3) I cause the ISP to tell me who you are.

	Under your attack model (3) is easy. But it is under any realistic
scenario, Ashcroft can (and will) simply issue a directive under the Patriot
act to force the ISP to hand over the records, Al Qaeda would simply kidnap
the Sysop's children and tell the sysop to give them the data.


		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: Friday, December 07, 2001 3:14 PM
> To: Hallam-Baker, Phillip
> Cc: 'Derek Atkins'; 'Walker, Jesse'; ipsec@lists.tislabs.com
> Subject: Re: Son-of-IKE Selection Criteria? 
> 
> 
> The real problem here is that it puts the local operator -- the ISP, 
> the hotel, the conference LAN organizers -- in the critical path.  If 
> one needs an address-based certificate, one can't do 
> *anything* without 
> local operator co-operation.  Apart from the fact that that doesn't 
> scale very well -- between last Tuesday and next Friday, I'll 
> have been 
> in four different cities, have used or will use at least four 
> different
> LANs (two of which used borrowed jacks and/or IP addresses), 
> etc., and 
> I'd have used more if airports and train stations (and, for that 
> matter, airplanes and trains) had 802.11 or Ethernet available.  Why 
> should I need to go through that many ISPs instead of having a 
> certificate (public key, actually) issued by my employer for 
> VPN access?
> 
> 
> 
> In message 
> <2F3EC696EAEED311BB2D009027C3F4F4058698B5@vhqpostal.verisign.com>, "
> Hallam-Baker, Phillip" writes:
> 
> >
> >First let us be clear about the different types of dynamic 
> address. In
> >practice very few addresses are genuinely 'dynamic'.
> >
> >Second, in this I will talk about 'certificates' since they 
> are what the
> >group are familliar with. But remember that this is simply a 
> shorthand for
> >'binding of data to a private key' and there might be a 
> scheme such as XKMS
> >supporting the use.
> >
> >1) The Address is actually static but is dynamically reallocated for
> >operational reasons.
> >	E.G. most cable modem addresses which rarely change 
> (unless excite
> >goes bankrupt that week).
> >
> >	Can issue a certificate bound to the IP address
> >
> >	If the IP address changes, revoke & reissue (note, 
> probably want to
> >use XKMS rather than CRLs!)
> >
> >2) The Address is dynamic being allocated each time from a 
> fixed pool.
> >	E.G. dial up access
> >
> >Here we have a number of approaches,
> >
> >A) Generate a key / cert for each address in the pool.
> >	When the initiator attempts to connect to the responder with the
> >client credential, the request is intercepted at the POP. 
> The POP first
> >performs a key agreement using the key bound to the IP 
> address, then once
> >the tunnel is created forwards the client request through the tunnel.
> >
> >B) Use disposable key / cert pairs.
> >	The initiator applies for a pool of key/cert pairs 
> which are cached.
> >These are discarded after a single use. The disposable 
> key/cert pair may not
> >even be certified by a trusted third party, it may be self signed.
> >
> >C) Issue a certificate that has a wild card in it
> >	E.G. 18.23.1.* (think binary mask)
> >
> >
> >While the cost of such systems may appear high the 
> concealment of identity
> >is inherently an expensive process IF DONE WELL. If the 
> concealment is poor
> >then better not to bother at all.
> 
>

Phillip