[vpn] Two Factor Authentication, was PKI authentication with VPN - was Cisco VPN 3000 authentication mechanisms

Kent Dallas kent at dalliesin.com
Thu Mar 21 10:15:56 EST 2002


Adam,

Allow me to explain my reasoning more clearly.  There are three basic types
of authenticators: something you know (PINS, passwords, shared secrets),
something you have (tokens, passport, drivers license), and something you
are (biometrics).  Systems based on two-factor authentication require at
least one authenticator from each of two different types (two passwords, for
example, are not considered two-factor authentication).

In the case we have been discussing, the "something you have" isn't your
smart card, or your PC, or the hard drive, it is the private key.  This is a
bit abstract since the private key is really just a string of bits, all ones
and zeros.  To be useful as an authenticator, the private key must be
unique, verifiable, and strictly possessed only by the entity/identity bound
with the corresponding public key in the certificate.  I'll avoid the PKI
101 discussion here, but note that asymmetric (public key) cryptography
differs from shared secrets since the private key IS NOT shared between the
two systems, but does allow for verification.  The PKI itself must enforce
the uniqueness of the private key.  And the user is responsible for
maintaining strict possession of the private key.

So how does the user do this?  They store the private key in a safe place.
They may store it in a software cryptographic store on their PC harddrive.
They may store it on a smart card, or perhaps a USB token.  In each case,
the user may protect access to the private key with a password.  And in each
case, the password is only of local significance, assigned by and only known
by the user.

Is a smart card more secure for storing a private key than a software
cryptographic store? Yes, particularly if the card has the ability to
generate the private key internally, perform signing and encryption
operations, and includes tamper-proof features.  Are software cryptography
stores insecure?  Hardly.  The difference is only a matter of degree.
Cracking a software cryptography store is non-trivial.  Further, it assumes
you have access to the PC, which in this case, in effect, acts the same as
the token (a secure storage device for the private key).

So why wouldn't the VPN solution you describe be considered two-factor
authentication?  The user needed both a password and a token, so it must be,
right?  I don't think so, and here is why.  From the VPN gateway's
perspective, the ONLY authenticator it validates is the private key (digital
signature).  The gateway DOES NOT know that the user had to (or did) enter a
password to access the private key - it never verified that the password was
correct - it didn't even KNOW the password.  All it knows is that the client
implementation had access to a valid private key.  That is ALL THE GATEWAY
can claim, a single factor, nothing more. Stated a little differently, what
do I need to break the security of the system?  The private key, and only
the private key, the password is irrelevent. That is a single factor
authentication solution (albeit a strong one).  I would be interested if
others on the list, particularly CISSPs, would agree or disagree.

A well designed single factor authentication system can be more secure than
a poorly designed two-factor system.  Two-factor authentication systems
normally include username/passwords as one of the two factors, since it is
relatively inexpensive to incorporate them.

With a proper design, this system can deliver security equivalent to many
two-factor systems.  But there are a whole host of other issues that must be
addressed, the most significant of which is the registration process of
binding the identity to the public/private key pair, including verification
that the private key is properly stored and protected in a smart card.  To
fulfill this requirement with high confidence almost always requires
face-to-face registration, which is simply impractical for the vast majority
of VPN implementations (particularly remote access, by its very nature).

My standard disclaimer:  The technology is great and wonderful, but even
with exceptional design, the weakest link will be the humans in the chain.
NO TECHNOLOGY can protect a system without proper POLICIES and PRACTICES,
process enforcement, training, monitoring, and auditing.  Otherwise, its
just a bunch of neat toys and a false sense of security.

And briefly, on your other points:
* If you are using an IPsec implementation with IKE, then the digital
signature exchange is encrypted, not with the cert, but with the key from
the DH exchange.
* If you are using LDAP and the directory stores user certs, then it is
unlikely that the client transmits the certificate with its authentication
request, just the distinguished name and signed challenge.
* Again, if it is IPsec with IKE, you have two authentication stages, a
group authentication and a user authentication.  It is unclear from your
post exactly how this is accomplished in your implementation.

Care to share the implementation you are using?

BTW, none of the information in this post is specific to the Cisco 3000.

Kent Dallas



VPN is sponsored by SecurityFocus.com





More information about the VPN mailing list