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

Re: Questions about PFS and ISAKMP SAs

-----BEGIN PGP SIGNED MESSAGE-----


  [Yes, Kai, I still owe you a reply from September :-)]

>>>>> "Kai" == Kai Martius <admin@imib.med.tu-dresden.de> writes:
    Kai> Michael,

    >> Questions:
    >> 
    >> 1. Is is reasonable to have multiple end points that need IPsec
    >> PFS using the same ISAKMP SA? Is PFS compatible in concept with
    >> sharing the ISAKMP SA?
    >> 
    >> 2. Does PFS extend to the ISAKMP SA? If we should be throwing
    >> away the ISAKMP SA's keys, and doing new exponentiations (and
    >> new authentications, since we can't use old keys to derive new
    >> keys when we need PFS), then how often do we do this for the
    >> ISAKMP SA?

    Kai> 2 points:

    Kai> first I think this is a matter of trust in the systems that
    Kai> perform the proxy exchange. Because they know the symmetric
    Kai> key material at the end of a phase 2 exchange a malicious
    Kai> system could store it somewhere for "message recovery"... No
    Kai> PFS or something else would help there.

  Agreed. The point being that one end or the other end may get
compromised, and/or the ISAKMP SA key may be brute force attacked. The
Phase II identities would then be available for a potentially very
long period of time. That may provide enough information in of itself
to constitute an attack. 

    Kai> second: assuming trusted ISAKMP servers use of DH exponents
    Kai> in phase II could significantly improve security: 1. If a
    Kai> PASSIVE attacker has cracked ISAKMP SA keys, he can't build
    Kai> the key to be exchanged in phase 2 (if he didn't breaked DH
    Kai> algorithm) because he only sees g^x and g^y, but can't derive

  Understood. Question #2 relates to PFS of identities. In the absense
of PFS for IPSEC keys, one tends to get PFS for identities, because
the DH pair runs out of entropy, and one does a new phase I
exchange. isakmp-oakley answers my #1 above in section 10:

   Perfect Forward Secrecy (PFS) of both keying material and identities
   is possible with this protocol. By specifying a Diffie-Hellman group,
   and passing public values in KE payloads, ISAKMP peers can establish
   PFS of keys-- the identities would be protected by SKEYID_e from the
   ISAKMP SA and would therefore not be protected by PFS. If PFS of both
   keying material and identities is desired, an ISAKMP peer MUST
   establish only one non-ISAKMP security association (e.g. IPsec
   Security Association) per ISAKMP SA. PFS for keys and identities is
   accomplished by deleting the ISAKMP SA (and optionally issuing a
   DELETE message) upon establishment of the single non-ISAKMP SA. In
   this way a phase one negotiation is uniquely tied to a single phase
   two negotiation, and the ISAKMP SA established during phase one
   negotiation is never used again.

  [which goes to show, that one should pretend to have not read any
drafts, and try and re-read everything as if one has never read the
draft before..]
  Perhaps, I should be asking: given that PFS of keying material requires
that one generate new keys at relatively frequent intervals, it is
desirable to get as many keys per DH exponent as possible. Perhaps,
one needn't delete the ISAKMP SA, but simply rekey it?

]       ON HUMILITY: to err is human. To moo, bovine.           |  SSH IPsec  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |international[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNHVm2cmxxiPyUBAxAQEimAL8Cvq6w4Z/2FCez9mfKrD4E8y/wzPqr72M
rUuJiuTJMzgwys3+NLF/dryC5/F8Rv0omzGa5/wMjp/cRlVPVin/n+3XvreKdZSq
REz8JAPCkijH7P9Id8uAUbPSB7BguSpo
=QvoQ
-----END PGP SIGNATURE-----
References: