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

Decrypting ID payload in Main Mode w/shared secrets



The Linux IPSEC implementation is trying to make shared secrets and
identity protection work for Road Warriors (laptops connected to any
place on the Internet, who want a secure tunnel back to home).  The
current IKE protocol makes this a problem.  Dan Harkins' succinct
description of the protocol problem is:

> The problem is the key used to encrypt the IKE messages is derived
> from SKEYID and if you're doing pre-shared key authentication SKEYID
> is derived from the pre-shared key. So, the issue is: how do I know
> the pre-shared key if I haven't gotten the guy's identity payload yet?
>
> ...  If you're doing Main Mode authenticated with pre-shared keys
> the pre-shared key has to be based on the IP address of the peer.
> For people with a dynamic IP address that is, indeed, problematic.

Now let's discuss proposed solutions.  Still quoting Dan:

>   The "solution" is to use Aggressive Mode and the KEY_ID identity
> which is basically an opaque blob that conveys no information to
> an evesdropper but can be bound to a pre-shared key by the real parties
> to the exchange.

This proposed solution permits eavesdroppers to determine that the same
person (the same opaque blob) is connecting from a variety of places,
even if they don't know the "identity" of that person.  (In Aggressive
Mode, the ID payload isn't protected under the D-H shared key.)

> That or use digital signatures since there is nothing
> in the SKEYID generation that is bound to the identity. Note though that 
> has been described as a weakness of digital signature mode (by Hugo 
> Krawczyk).

Digital signatures are a whole other interesting topic; let's stick with
shared secrets for a bit.

>   Alternately a "solution" would be to define a new exchange that has
> the negotiation richness of Main Mode (which is the drawback to Aggressive
> Mode) but does not have identity protection. 

Since I don't want to give up identity protection, this doesn't suit.

I have a proposal that provides identity protection against passive
attacks, allows the parties to negotiate their identities, and only
uses shared secrets.

My suggestion is that the "pre-shared key" used to generate SKEYID for
the third exchange in Main Mode (the ID payload and the hash) be set
to some generic open secret, unless the parties know a secret specific
to their IP addresses.  Then, after processing these third exchange
packets, both parties will change the SKEYID for future packets, by
picking a more appropriate pre-shared secret based on the identities
claimed in the third exchange.  This new SKEYID would protect the
subsequent Quick Mode exchange(s) that actually set up IPSEC SAs.

I suggest that in the absence of explicit configuration, the generic
open secret be the ASCII string:

	"open secret"

The convention that an open secret is used for the 3rd packet's SKEYID
is consistent with the existing IKE specs, which say "When using
pre-shared key authentication with Main Mode the key can only be
identified by the IP address of the peers since HASH_I must be
computed before the initiator has processed IDir."  The open secret is
associated with any IP address for which no other configured secret
key exists.

Such an open secret is similar to the single "secret shared by all
Road Warriors" provided in freeswan-1.00 as the key for IP address
0.0.0.0.  If a community of users (in a single VPN) wish to change
this open secret to a less-open secret, they would only need to
configure a secret key for IP address 0.0.0.0.  The advantage of
today's proposal (changing the key after packet #3) is that the secret
shared with the entire group would then be replaced for all subsequent
packets by a secret shared only by the parties involved.

> The other option, which is
> to remove the pre-shared key from SKEYID generation, has already been
> rejected by the WG due to the security impact (again, noted by Hugo).

Using an open secret as the pre-shared secret (as opposed to
configuring a secret shared by your entire VPN) would seem to have the
same security implications as removing the pre-shared secret from the
SKEYID generation.  I am still looking for the mailing list messages
in which Hugo discussed the security implications of such a change.
SKEYID was created in draft-ietf-ipsec-isakmp-oakley-03.  I
found a lively discussion that started with a message by Hugo on 25
Sep 1997, about changes between drafts 3 and 4 in SKEYID generation,
and his proposal for further changes.  However, this discussion was
all about the "encryption mode" of Main Mode (using public keys to
authenticate), not about the pre-shared key mode of Main Mode (using
pre-shared secrets to authenticate).  I found no reference to any
insecurities in removing *pre-shared secrets* from SKEYID generation.
Can someone feed me a better clue here?

	John



Follow-Ups: