[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on CRACK
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,