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

Re: Comment on xauth and hybrid



Dennis Glatting wrote:

> I must first admit I had not read the xauth and hybrid drafts until
> after the IPsec meeting where concerns were raised about weakening
> IPsec by supporting legacy authentication systems. As a manager and
> advisor of several enterprises I certainly understand the
> "transitional" intent of these documents. In fact, I could easily be
> one calling for their existence and demanding their implementation.
> However, as that same manager and advisor I can confidently tell you
> legacy systems, no matter their function, remain in-place and key
> infrastructure components longer than they should.
>
> 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'd like to point out another thing,
Xauth/Hybrid is criticized on the grounds that it allows use of passwords.

There is no doubt that passwords do not provide good security.
However Xauth/Hybrid can be used with strong user authentication
mechanisms such as -
SecurID, DES Gold etc. I believe these methods offer better security than
IKE pre-shared keys authentication.

>
> Perhaps not using managed shared secret technologies but I look to the
> SSL/TLS web reality of today as a crystal ball of the future of a
> widely deployed xauth/hybrid IPsec. I do a fair amount of on-line
> purchasing. For some ten sites I have, to my dismay, several user
> identifiers and passwords housed in ten different databases managed by
> staffs with ten different philosophies on security and skill sets. Not
> once have I been prompted by my browsers for the password to decrypt
> my private key. Not once. If these sites supported client side
> certificates I would not have to create an identifier, divulge a
> password, or write these things down on a piece of paper and tuck it
> away in my wallet. Further, I remember reading about a survey by
> Netcraft where only 5% of the web sites they queried offering server
> side certificates offered valid certificates. My concern is
> xauth/hybrid effectively reduce IPsec to the SSL/TLS reality of today
> (i.e., we really haven't improved things).

I understand your concern, but these concerns should not be limited to the
remote access scenario.
Nothing prevents an IKE implementation from accepting an invalid
certificate except for the IPSec RFCs.
Xauth/Hybrid is not different. An IKE implementation that supports
Xauth/Hybrid should still confirm to the standard IPSec RFCs and it is
therefore not exempt from certification validation.


>
> 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.
Follow-Ups: References: