Re: Comments on CRACK

["Steven M. Bellovin" <smb@xxxxxxxxxxxxxxxx>]

In message <38161BDE.619E2F7A@xxxxxxxxxxxx>, Ricky Charlet writes:
> "Steven M. Bellovin" wrote:
> > 
> > In message <3815F49E.BFABF7C9@xxxxxxxxx>, Roy Pereira writes:
> > 
> > >
> > > Let me ask everyone who is interested;  How do we support existing
> > > legacy user authentication within IKE without using a PKI ?
> > 
> > With a protocol that lets the customer download an encrypted private key/
> > certificate pair from a server, followed by ordinary IKE.
> > 
> >                 --Steve Bellovin
> 
> 
> Howdy ()
> 	<This note was sent to only the ipsra list>
> 
> 
> 	I always hate when people put words in my mouth, but just to make sure
> I understand, are you saying that:
> 
> 	A PKI, with per user granularity, 'MUST' be used to solve IPSec remote
> access authentication?

No, that's far too strong a statement.

First, invoking the magic acronym "PKI" conjures up images of a vast, complex 
structure.  This "PKI" has the scope of the users of a single remote access 
facility.  It need only be protected to the extent that you'd protect any 
other means of remote access to your network -- if you're not using 
TEMPEST-shielded rooms for your RADIUS database, you don't need them for this 
"PKI", either.  Second, you don't even need persistent certificates.  You can, 
instead, generate them dynamically and send the public/private keypair to the 
user (or let the user generate them and get the certificate signed, under 
control of the legacy authentication mechanism you like).  Again, these 
certificates aren't good for electronic banking or even email; they're simply 
used for remote access.

The point is that this scheme avoids complicating an already-complex protocol.
It leaves the strong authentication mechanism -- certificates -- in place, and 
lets you use weaker mechanisms for the users you choose, and only until you 
can phase out that stuff and replace it with, for example, smart cards.  It 
also avoids all issues of group-shared secrets (the technical term for which 
is "great gaping security hole"), compatibility with the myriad modes of IKE,
etc.

		--Steve Bellovin