Vulnerability with Group Password (Device Authentication)?

[gasparie]

In a VPN 3000 Concentrator config, what are the ramifications of an unauthorised user knowing the group username and password?

I have a situation where a proposed solution has a single group defined, which all users are part of. The group username and password and stored on the client configuration within the .pcf config file. The password is encrypted, but I'm assuming this can be cracked with brute force/dictionary attacks.

In addition to group authorisation, users must be authenticated with strong token OTP. This is a good thing and gives me comfortable assurance that only legitimate users are actually getting access to the private network.

My concern is what can be done with the group credentials. Is this used as a seed for any key generation or setup of the IPsec tunnel? Can they be used to perform man in the middle, replay or eavesdropping sessions?

Concerned ...

[paqiu]

The group password is using for ISAKMP pre-shared key. It build up the IPSEC phase 1 negotiation. It will use Diffie-Hellman key exchange method to generate and exhange the session key.

The session key will protect the phase 2 ipsec encryption tunnel to pass the data taffic.

The group redential can not be used to perform man in the middle, replay or eavesdropping sessions. Because phase 1 negotiation itself has des/3des, HMAC-MD5 or HMAC-SHA to protect the key exchange.

Please check more details in

http://www.cisco.com/warp/public/cc/techno/protocol/ipsecur/ipsec/prodlit/dplip_in.htm

Even someone got your group credential, without passing user authentication to build up a VPN tunnel, group credential will be totally useless for him.

Because he can not use group redential to do anything to other people's VPN sessions.

Best Regards,

[gasparie]

As per RFC 2048, Section 1.5.3:

1.5.3 ISAKMP Requirements

Strong authentication MUST be provided on ISAKMP exchanges. Without

being able to authenticate the entity at the other end, the Security

Association (SA) and session key established are suspect. Without

authentication you are unable to trust an entity's identification,

which makes access control questionable. While encryption (e.g.

ESP) and integrity (e.g. AH) will protect subsequent communications

from passive eavesdroppers, without authentication it is possible

that the SA and key may have been established with an adversary who

performed an active man-in-the-middle attack and is now stealing all

your personal data.

If I have the group password, I can determine the session key that is generated for Phase2 encryption. This means that I can decrypt the entire session. In my earlier example, I agree with you that with strong user authentication, further access into the private network is not possible.

My contention is that with shared group passwords, any IPsec session is subject to capture/decryption and therefore data is not confidential. The only way (that I can see) to ensure confidentiality and integrity of the IPsec session is to employ strong device authentication (with certificates).

Also, related to group passwords, what is the point in being able to store the group password in the client PCF file? If we store the password in plain text, we just need to know how this is hashed (I would immediately guess MD5). If we store the encrypted value, then we don't need to know anything - this is the hashed value that is compared between the two ends. Either way, there appears to be little value in having the ability to store this value - apart from making this part of the connection transparent to the end user. From a security perspective it makes no sense.

I'd appreciate your comments on this ....

Edy

[paqiu]

Even you are using certifercate, the problem will not be avoided. Because someone can access the laptop and export the digital certificate out and import it to another PC. It is the same story as your group name and password has been known by someone else.

If you really want to highly secure your phase 1 ISAKMP, some of our customers using Smartcard with certificate.

Without physically took the Smartcard and plug it into your own PC, you can not pass the ISAKMP negotiation.

If you config Certificate with CRL, then if one guy lost the Smartcard, he report to the administator. The adminstrator revoke the cert , that Smartcard with the certificate will be useless for the guy stolen the Smartcard.

This way might answer your question better ?

Best Regards,

[gasparie]

By using certificates, you have the advantage of revoking the cert should a laptop be lost/stolen (as you suggest) and not compromise the entire solution. I don't think the security is the same as group password - the private certificate would be protected by a passphrase which is never stored. So, if someone stole my pair of keys, then without the passphrase it's useless.

Thanks for your previous comments - you have confirmed my concerns with group passwords and risk of using them.

[lmoushouras]

Hello,

Do you know if I can use smartcard without hardware reader only software?

Best Regards