[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment on xauth and hybrid
On Wed, 21 Jul 1999, Tamir Zegman wrote:
>
>
>
> "Scott G. Kelly" wrote:
>
> > Tamir Zegman wrote:
> > >
> > > Dennis Glatting wrote:
> > >
> > <trimmed...>
> > > > The PKI reality is there isn't one, so shared secrets, I expect, will
> > > > be the IPsec authentication mechanism of choice until products mature
> > > > and prices decline. The difference between simple shared secrets and
> > > > xauth/hybrid is xauth/hybrid extends existing, seemingly easy to
> > > > manage, managed shared secret technologies yielding, in my opinion, no
> > > > motivation to improve the security of infrastructures (i.e.,
> > > > transition to PKI). Is this where we want to be after several years of
> > > > work and some cantankerous meetings?
> > > >
> > >
> > > There is another side for this coin.
> > > We have many customers that are deferring their migration to IPSec because
> > > they feel they are not ready to deploy a full scale PKI.
> > > Xauth/Hybrid makes the move to IPSec easier and allows gradual deployment
> > > of PKI.
> > > Sometimes it's easier to jump over two small hurdles rather than over a
> > > big one.
> >
> > I agree with Tamir on this point, but think that if we are indeed
> > viewing this (xauth, hybrid) as an intermediate step, then we should
> > make this exceedingly clear, and the transition path should be clearly
> > stated ("clearly" being a relative term at this point in the game).
> >
> > <more trimmed...>
> >
> > > >
> > > > I offer the following suggestions. First, finish a combined
> > > > xauth/hybrid draft and classify it as experimental. Second, the
> > > > Security Considerations section of the draft be written not by the
> > > > draft's proponents but by at least two of its detractors. Finally, set
> > > > a deadline (perhaps three years) where the PS is committed to
> > > > historic.
> > >
> > > I'll accept your offer with regard to the Security Consideration section.
> > > Any volunteers?
> > > I do not believe that the experimental is the right track for this.
> >
> > I'd be willing to contribute to the security considerations text.
> >
> > I'm not sure if the experimental track is right or not, though I do
> > think that somehow limiting the lifetime of password-based approaches
> > has a certain appeal. We must grease the skids for PKI deployment, and
> > not simply provide an excuse for maintaining the status quo, but this is
> > a complex issue. That is why I think we need a working group to iron it
> > out.
> >
> > Scott
>
> Hi Scott,
>
> I think that there is a consensus that static passwords are BAD.
> XAUTH/Hybrid are not there to support static passwords but to
> support stronger authentication schemes. In some cases PKI with
> "soft" tokens are even less secure than legacy authentication
> schemes such as SecurID tokens. In the absence of PKI, IKE users
> will fall back to use pre-shared keys. Do we want that? In some
> aspects IKE pre-shared secrets are even less secure than
> XAUTH/Hybrid with fixed passwords since they are susceptible to
> off-line dictionary attacks. Why not ban pre-shared secrets?
>
One of the key differences is XAUTH/hybrid provides no incentive to
move to PKI whereas pre-shared secrets by virtue of being unmanageable
does. However, just to throw a little personal experience for
perspective in favor of shared secrets, whether XAUTH/hybrid provided
or pre-shared secrets, I offer the following story.
One of my clients has an IKE capable firewall. I decided to purchase
the vendor's certificate based solution because I believe a
certificate based solution offers better security, it inexpensively
introduces my client to certificate based thinking, and it was a
slam-dunk -- I didn't have to think about it. :) I purchased the
recently released software in May of 1999 and discovered, after five
weeks, I had to downgrade my NT server to a non-y2k patch level and
the software itself wasn't y2k. I returned the software and went the
pre-shared secret route.
Even with PKI there is still a password problem: the user's password
used to encrypt their private key. People do stupid things including
choosing stupid passwords. Many users still write their passwords on
pieces of paper and attach them to their terminals, or write them down
on mouse pads, or write them down on a sheet just inside their top
desk drawer, sometimes labeled "password." In one case a women could
not remember her ID and password to save her life. Eventually I
changed her password to her husband's name without any character
substitutions. She could not remember that one, too. So, whether you
are using certificates, smart cards, or anything else that is password
related, the question is: what's the difference between having
xauth/hybrid and not having it? Strictly looking at passwords, a
central service can impose good password selection mechanisms as can
client software; However, a central service is in a better position to
perform an off-line dictionary attack to assure good choice.
When I think about the problems xauth/hybrid address I think of Bart
Simpson's immortal words (stolen from somewhere else, I bet) "you're
damned if you do and you're damned if you don't." I believe
XAUTH/hybrid offers something valuable but should not be encouraged.
-dpg
Follow-Ups:
References: