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

Re: Decrypting ID payload in Main Mode w/shared secrets



  You must have some out-of-band mechanism to distribute this pre-shared
key (the real one, not the "open secret") on the scale you desire so
why not just distribute public keys bound to identities through that
channel and then use the pubic key encryption mode? This gives you 
deniability and also makes an attacker crack not only the Diffie-Hellman 
but two public key encryptions. 

  If the RSA patent is in your way then define a new exchange which uses 
El-Gamal. What you propose would require another exchange anyway since 
everyone else's implementation doesn't create one set of SKEYID(a_e_d) 
state and then throw it away and make more.

  Using a well-known pre-shared key would mean that anybody who knows
it could derive the key used to encrypt the identities (which is now based
completely on known information: "open secret" and the 2 nonces which are
passed in the clear) and that sort of defeats your purpose. 

  And why "open secret" when we have draft-ietf-ipsec-internet-key-00.txt?

  Dan.

On Tue, 27 Apr 1999 14:21:40 PDT you wrote
> 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: References: