Re: IPsec +- Perfect Forward Secrecy
Eric Rescorla <[EMAIL PROTECTED]> writes:
> John Denker <[EMAIL PROTECTED]> writes:
> > Eric Rescorla wrote:
> >
> >> Uh, you've just described the ephemeral DH mode that IPsec
> >> always uses and SSL provides.
> >
> > I'm mystified by the word "always" there, and/or perhaps by
> > the definition of Perfect Forward Secrecy. Here's the dilemma:
> >
> > On the one hand, it would seem to the extent that you use
> > ephemeral DH exponents, the very ephemerality should do most
> > (all?) of what PFS is supposed to do. If not, why not?
> >
> > And yes, IPsec always has ephemeral DH exponents lying around.
> >
> > On the other hand, there are IPsec modes that are deemed to
> > not provide PFS. See e.g. section 5.5 of
> >http://www.faqs.org/rfcs/rfc2409.html
>
> Sorry, when I said IPsec I mean IKE. I keep trying to forget
> about the manual keying modes. AFAICT IKE always uses the
> DH exchange as part of establishment.
IKE always performs DH as part of phase 1 ("Main Mode" or "Aggressive
Mode"), which authenticates and produces long-term keys for phase 2
and similar. In phase 2 ("Quick Mode"), which actually produces IPsec
SAs, one can optionally perform an additional DH for PFS.
--
This message may contain confidential and/or proprietary information, and
is intended only for the person/entity to whom it was originally addressed.
The content of this message may contain private views and opinions which do
not constitute a formal disclosure or commitment unless specifically stated.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IPsec +- Perfect Forward Secrecy
OK, let me ask a more specific question. Actually, let me put forth some hypotheses about how I think it works, and see if anyone has corrections or comments. 0) I'm not sure the words Perfect Forward Secrecy convey what we mean when we talk about PFS. Definition 12.16 in HAC suggests _break-backward protection_ as an alternative, and I prefer that. Perhaps the complementary concept of break-back _exposure_ would be even more useful. http://www.cacr.math.uwaterloo.ca/hac/ http://www.cacr.math.uwaterloo.ca/hac/about/chap12.pdf I think for today we don't have a simple yes/no question as to whether the secrecy is "perfect"; instead we have multiple quantitative questions as to which connections have how much break-back exposure. 1) First an ISAKMP SA is set up, then it is used to negotiate one or more IPsec SAs, which carry the traffic. 2) Ephmeral DH is always used on the ISAKMP SA, so the ISAKMP session has no more than one ISAKMP session's worth of break-back exposure. That is, the attacker who steals an ISAKMP session key can read that session, but (so far as we know :-) does not thereby gain any head-start toward reading earlier ISAKMP sessions. 3) Each IPsec SA has its own session key. The stated purpose of Quick Mode is to provide "fresh" keying material. "Nonces" are used. As I understand it, that means the IPsec session keys are sufficiently ephemeral that each IPsec session has no more than one IPsec session's worth of break-back exposure. That is, the attacker who steals an IPsec session key can read that session, but does not (sfawk :-) gain any head-start toward reading earlier IPsec sessions. 4) As far as I can tell, the only interesting question is whether a break of the ISAKMP session is _inherited_ by the IPsec sessions set up using that ISAKMP session. The break of an IPsec session will not spread at all. The break of an ISAKMP session will not spread beyond that ISAKMP session ... but what happens within that ISAKMP session? The answer, as I understand it, depends on the setting of the misleadingly-named "IPsec PFS" option. If the option is set, there is an additional layer of opacity on a per-IPsec-SA basis, so that a break of the ISAKMP session is not inherited by its IPsec SAs. Bottom line: As I understand it, IPsec always has reasonably tight limit on the amount of break-back exposure, but setting the so-called "PFS" option reduces the exposure further ... roughly speaking, by a factor of the number of IPsec SAs per ISAKMP SA. Comments, anyone? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IPsec +- Perfect Forward Secrecy
On Wed, Dec 01, 2004 at 01:45:15PM -0500, John Denker wrote:
> Eric Rescorla wrote:
>
> >Uh, you've just described the ephemeral DH mode that IPsec
> >always uses and SSL provides.
>
> I'm mystified by the word "always" there, and/or perhaps by
> the definition of Perfect Forward Secrecy. Here's the dilemma:
>
> On the one hand, it would seem to the extent that you use
> ephemeral DH exponents, the very ephemerality should do most
> (all?) of what PFS is supposed to do. If not, why not?
>
> And yes, IPsec always has ephemeral DH exponents lying around.
>
> On the other hand, there are IPsec modes that are deemed to
> not provide PFS. See e.g. section 5.5 of
> http://www.faqs.org/rfcs/rfc2409.html
>
> Perhaps the resolution of the dilemma is to say that IPsec
> "always" uses ephemeral DH for _some_ things, but it does not
> "always" use ephemeral DH for some _other_ things. Right?
I apologize in advance to all IPsec-knowledgeable readers for using
imprecise terminology.
There are two types of Security Associations (encrypted channels) involved.
The first, called an "ISAKMP SA", is strictly for control traffic between
the IPsec peers ("management metadata"). The other type is an "IPsec SA",
which is for "real" data.
The negotiation to establish an ISAKMP SA *always* involves a DH exchange.
In fact, in "main mode", there are three pairs of messages: parameter
exchange (encryption algorithm, hashing algorithm, authentication mechanism),
DH exchange, and then authentication. The ISAKMP SA is really set up at the
end of the DH exchange; the first order of business is to do authentication
over the encrypted channel to prevent a man-in-the-middle attack.
On the other hand, the ISAKMP mode to negotiate an IPsec SA is called "quick
mode". It is expected that that mode does not involve costly cryptographic
operations (such as a DH exchange). The keys for an IPsec SA are derived
from keying material established in the ISAKMP SA negotiation. If one wants
PFS for IPsec SAs, then one includes a DH exchange in the quick mode
negotiation (thereby turning it into a "not-so-quick mode" negotiation?).
So, to summarize:
- DH exchange always happens for ISAKMP SA setup
- DH exchange may or may not happen for IPsec SA setup
OK, back to lurking ...
- Ken
>
> Also note that 'ephemeral' is not a binary predicate. Some
> things are more ephemeral than others. Can you also have
> more-perfect PFS and less-perfect PFS?
>
> ===
>
> There are plenty of things out there (including Cisco boxes,
> in the default configuration) where the IPsec does not have
> PFS turned on.
>
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
>
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IPsec +- Perfect Forward Secrecy
John Denker <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > >> Uh, you've just described the ephemeral DH mode that IPsec >> always uses and SSL provides. > > I'm mystified by the word "always" there, and/or perhaps by > the definition of Perfect Forward Secrecy. Here's the dilemma: > > On the one hand, it would seem to the extent that you use > ephemeral DH exponents, the very ephemerality should do most > (all?) of what PFS is supposed to do. If not, why not? > > And yes, IPsec always has ephemeral DH exponents lying around. > > On the other hand, there are IPsec modes that are deemed to > not provide PFS. See e.g. section 5.5 of >http://www.faqs.org/rfcs/rfc2409.html Sorry, when I said IPsec I mean IKE. I keep trying to forget about the manual keying modes. AFAICT IKE always uses the DH exchange as part of establishment. -Ekr - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: IPsec +- Perfect Forward Secrecy
Eric Rescorla wrote: Uh, you've just described the ephemeral DH mode that IPsec always uses and SSL provides. I'm mystified by the word "always" there, and/or perhaps by the definition of Perfect Forward Secrecy. Here's the dilemma: On the one hand, it would seem to the extent that you use ephemeral DH exponents, the very ephemerality should do most (all?) of what PFS is supposed to do. If not, why not? And yes, IPsec always has ephemeral DH exponents lying around. On the other hand, there are IPsec modes that are deemed to not provide PFS. See e.g. section 5.5 of http://www.faqs.org/rfcs/rfc2409.html Perhaps the resolution of the dilemma is to say that IPsec "always" uses ephemeral DH for _some_ things, but it does not "always" use ephemeral DH for some _other_ things. Right? Also note that 'ephemeral' is not a binary predicate. Some things are more ephemeral than others. Can you also have more-perfect PFS and less-perfect PFS? === There are plenty of things out there (including Cisco boxes, in the default configuration) where the IPsec does not have PFS turned on. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
