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

Re: Comment on xauth and hybrid

Certificate authentication is prone to key board monitoring attack.
If one leaves the hard token in the PCMCIA slot, it is as weak as
a soft token.

Y. John Jiang, Internet Engineer, Internet Security, Cable and Wireless
703-715-7480, 2100 Reston Parkway, Reston, VA  20191

On Wed, 21 Jul 1999, Dennis Glatting wrote:

> 
> 
> 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: