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

RE: xauth requirements: vulnerabilities

Hi Dan,

>   You can say in the largest font possible and underlined as 
> much as you
> want, "Be extremely careful not to bypass IKE's security by choosing a
> weak shared secret" but the very use of this pre-shared key will make
> it weak! There is a fundamental limit in IKE that to use pre-shared
> keys (with Main Mode) means that the pre-shared key is bound to an IP
> address. Since you cannot know the IP address of these remote clients
> a priori you MUST use a shared group secret. That is by 
> definition weak.

The ID doesn't need to be bound to an IP Address in Aggressive Mode or Base
Mode.  It could be a known unique value for each remote user.

> 
>   FIPS 112 deals with passwords that are personal. You cannot 
> use a FIPS 112
> password in this environment. 

I believe that FIPS 112 has a set of rules that one may follow to choose a
"good" password.  Regardless, one could restrict the the admin from using a
password that is less than 10 characters in length, at least one uppercase,
one lower case, one numeric, etc...

You also cannot go around 
> changing the password
> every day because you'd orphan all the people out on the road 
> (unless you
> somehow announced to all what the new "secret" was so they 
> could update 
> their laptops but the problem with that is, I hope, obvious). 

Yes, I wasn't really being serious by suggesting this.

> I don't know
> how you can say such things as "an implementation could 
> easily restrict the 
> network admin from using a 'global' shared secret" when you 
> know that that 
> is impossible.

See above comments on using an ID with Base Mode or Aggressive Mode.

> 
>   If a requirement of XAUTH is to provide legacy 
> authentication without
> "diminishing the security of IPSec itself" please tell me how 
> you intend
> to do this? 
> 
>   The real problem I see with XAUTH is that it promotes and encourages
> and legitimizes an insecure use of IKE and IPSec.
> 

One of the problems lies in the fact that IPSec doesn't prohibit the use of
"weak" shared secrets.  Certainly a less security-concious person may be
more inclined to use a "weak" shared secret when using XAUTH (despite my
bold and triple underlined warning), but nothing prevents a less
security-concious person from doing the exact same thing when XAUTH isn't
there.  There are methods that one could use to ensure that the shared
secret be unique and strong, but IPSec doesn't mandate them.

Regards,
Stephane.
Follow-Ups: